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The  implementation  guidelines  presented  in  Volumes  I  and  II 
were  developed  by  the  Department  of  Defense  (DoD)  for  new 
participants  in  the  electronic  data  interchange  (EDI)  program  and 
for  documenting  DoD’s  EDI  data  requirements. 

Volume  I  contains  Chapters  1-9.  Those  chapters  describe  the 
background,  scope,  and  main  issues  that  need  to  be  considered 
when  implementing  EDI. 

Volume  II  contains  Chapter  10  only;  it  establishes  a  baseline 
of  DoD’s  conventions  for  implementing  the  American  National 
Standards  Institute  (ANSI)  Accredited  Standards  Committee 
(ASC)  X12  uniform  standards  for  electronic  interchange  of 
business  transactions.  This  baseline  is  not  all-encompassing. 
Functional  analysts  may  need  to  supplement  the  conventions 
to  further  clarify  their  use  in  a  specific  functional  application 
such  as  the  use  of  the  810  Invoice  for  progress  payments  or 
use  of  the  856  Ship  Notice/Manifest  for  the  transfer  or  sale 
of  an  aviation  fuel  product.  This  type  of  supplement,  called 
an  application-specific  convention,  is  permitted. 

In  the  application-specific  convention,  data  segments  and  data 
elements  must  comply  with  the  conventions  as  defined  in  the 
guidelines.  If  the  convention  does  not  meet  your  needs,  you 
can  request  a  convention  be  changed  to  include  your  specific 
data  requirements.  Chapter  5,  Maintenance,  explains  where  to 
send  your  comments  and  how  to  make  changes  to  the  conven¬ 
tions  by  submitting  data  maintenance  requests. 

To  determine  whether  an  application-specific  convention  exists, 
you  should  contact  the  DoD  Executive  Agent  for  EDI  at  the 
address  below: 

DoD  Executive  Agent  for  EDI 
Defense  Logistics  Agency 
ATTN:  DLA-ZIE 
Cameron  Station 
Alexandria,  VA  22304-6100 
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1.0  INTRODUCTION 

This  chapter  explains  the  purpose  of  these  guidelines,  the  scope 
of  the  guidance,  the  authority  for  publishing  a  general  introduc¬ 
tion  to  EDI  and  an  explanation  of  how  to  use  the  guidelines. 

1.1  PURPOSE  OF  THE  GUIDELINES 

These  guidelines  provide  general  guidance  on  the  implementation 
of  American  National  Standards  Institute  (ANSI)  Accredited 
Standards  Committee  (ASC)  X12  electronic  data  interchange 
(EDI)  standards  within  automated  information  systems  (AIS)  and 
information  interchange  procedures  that  require  the  collection, 
reporting,  and/or  exchange  of  data  needed  to  perform  Defense 
missions. 

1.2  SCOPE 

The  guidance  is  provided  for  two  components.  First,  it  may  be 
used  by  organizational  elements  of  the  DoD  conununity.  It  may 
also  be  useful  to  organizations  external  to  DoD  that  exchange 
data  with  the  DoD  community  in  the  course  of  their  business 
relationships.  Many  of  these  organizations  also  engage  in  the 
planning,  development,  test  and  evaluation,  standardization,  im¬ 
plementation  and/or  maintenance  of  ANSI  ASC  X12  standards 
in  automated  system  applications  and  associated  information 
interchange  procedures. 

The  DoD  community  encompasses  the  Military  Services,  Organiza¬ 
tions  of  the  Joint  Chiefs  of  Staff,  Unified  and  Specified  Commands, 
Office  of  the  Secretary  of  Defense,  and  the  Defense  agencies.  (That 
community  is  collectively  referred  to  as  the  DoD  Components.) 

Organizational  entities  external  to  DoD  include  (a)  non-Govem- 
ment  organizations,  both  commercial  and  nonproHt;  (b)  Federal 
agencies  of  the  United  States  Government  other  than  DoD; 
(c)  local  and  state  governments;  (d)  foreign  national  govern¬ 
ments;  and  (e)  international  government  organizations. 

1.2.1  Adoption 

The  conventions  published  in  this  document  are  for  trial  use  and 
comment.  DoD  Components  that  are  now  using  ASC  X12 
standards  or  industry-specific  standards  may  continue  to  do  so 
and  convert  to  DoD  conventions  at  an  appropriate  time  (e.g., 
major  system  change  or  revision  of  the  standard  used).  How¬ 
ever,  such  DoD  Components  must  submit  to  the  DoD  EDI 
Executive  Agent  (EA)  their  data  requirements  that  are  not 
covered  in  the  conventions  as  soon  as  possible,  as  indicated  in 
Chapter  S.O,  Section  S.1.1. 

New  implementations  must  use  the  DoD  conventions.  If  no 
convention  exists  or  if  changes  are  needed,  DoD  Components 


must  submit  their  requirements  as  indicated  in  Chapter  5.0, 
Section  S.1.1. 

1.2.2  Waivers 

Waivers  will  be  granted  by  the  DoD  EA  if  compliance  would 
adversely  affect  mission  accomplishment  or  have  a  major  finan¬ 
cial  impact  that  is  not  offset  by  DoD-wide  savings.  Waiver 
requests  should  be  submitted  to: 

DoD  EDI  Executive  Agent 
ATTN:  DLA-ZIE 
Cameron  Station 
Alexandria,  VA  22304-6100 

1.3  RESPONSIBLE  ENTITY 

The  Defense  Logistics  Agency  (DLA)  is  DoD’s  Executive  Agent 
for  implementing  and  maintaining  Defense-wide  programs  for 
(a)  EDI  in  accordance  with  DepSecDef  memorandum  of  May  24, 
1988,  Subject:  Electronic  Data  Interchange  of  Business-Related 
Transactions;  and  (b)  Protection  of  Logistics  Unclassified/Sensi¬ 
tive  Systems  (PLUS)  in  accordance  with  Assistant  Secretary  of 
Defense  (Production  and  Logistics)  [ASD(P&L)]  memorandum  of 
November  21,  1989,  Subject:  Production  and  Logistics  Task 
Group  for  Data  Protection.  Publication  of  these  guidelines  is 
based  upon  this  authority.  See  Chapter  S.O  Maintenance  for 
office  point  of  contact. 

1.4  INTRODUCTION  TO  EDI 

Electronic  data  interchange  can  take  many  forms.  The  following 
helps  define  EDI. 

1.4.1  What  Is  EDI? 

Electronic  data  interchange  is  the  computer-to-computer  exchange 
of  routine  digital  business  information  in  an  agreed  upon  stan¬ 
dard.  It  is  conunonplace  in  many  private  companies  and  promises 
to  become  the  preferred  method  for  conducting  all  business  in 
the  future.  With  the  appropriate  computer  hardware,  software, 
and  communications,  businesses  can  eliminate  the  tedious  flow 
of  paper  purchase  orders,  invoices,  shipping  forms,  technical 
specifications,  and  other  documents  and  replace  them  with  their 
electronic  equivalents.  The  motivations  to  do  so  are  impelling: 
the  typical  costs  for  processing  a  multipart  document  from 
“cradle  to  grave”  can  range  from  $10  to  $40  or  more,  and 
conducting  business  electronically  can  slash  those  costs  by  a  third 
to  a  half.  Other  benefits  are  discussed  in  Section  1.4.6. 

1 .4.2  What  Is  New  About  EDI? 

Certainly  the  computer-to-computer  interchange  of  information  is 
not  new  to  American  industry  nor  to  the  Department  of  Defense. 
Since  the  mid-19S0s,  large  private  companies  and  DoD  activities 
have  been  electronically  conununicating  business  information. 
Because  each  user  conununicated  in  a  unique  format,  however, 
businesses  found  it  cumbersome  and  time  consuming  to  expand 
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their  electronic  communications  to  new  customer  (trading 
partners). 

What  is  new  is  the  emergence  of  nationally  and  internationally 
recognized  data  formats,  commonly  referred  to  as  standards  or 
transaction  sets,  that  serve  to  broaden  and  ease  the  interchange 
of  data.  These  commercial  standards  eliminate  the  need  to  create 
special  software  to  receive  or  send  user-unique  data  formats. 
Instead,  one  software  package  designed  to  generate  and  interpret 
standard  formats  can  be  used  to  exchange  information  with  all 
trading  partners.  And,  interestingly,  many  companies  are  now 
using  these  same  standards  to  facilitate  their  internal  exchange 
of  information. 

1 .4.3  Who  Creates  These  Standards? 

Two  key  standards  groups  developed  the  standards  for  North 
America:  the  Transportation  Data  Coordinating  Committee 

(TDCC)  and  ANSI.  The  TDCC,  formed  in  the  late  1960s, 
initially  concentrated  its  efforts  on  creating  transportation  stan¬ 
dards  for  the  rail,  motor,  air,  and  ocean  industries.  Its  success 
led  other  industry  groups  to  seek  its  help;  the  grocery,  chemical, 
and  warehousing  industries,  to  name  a  few.  As  the  TDCC  created 
industry-oriented  standards,  some  companies  and  individuals  that 
used  them  saw  the  need  for  generic  standards  that  cut  across 
industry  boundaries. 

In  1979,  ANSI  formed  the  ASC  X12  to  do  just  that:  develop 
uniform  standards  for  electronically  interchanging  digital  business 
transactions  between  and  among  industries.  What  this  means  is 
that  the  automotive  industry,  for  exanqile,  can  now  use  a  single 
standard  to  exchange  electronic  purchase  orders,  invoices,  and 
technical  specifications  with  chemical,  textile,  and  steel  industries. 

The  TDCC  and  ANSI,  through  the  Joint  Electronic  Data  Inter¬ 
change  Committee,  have  created  and  published  a  data  dictionary 
that  provides  for  common  data  elements,  segments,  and  codes, 
in  essence  a  common  set  of  deEnitions  and  terms  for  creating 
standards. 

1 .4.4  What  Resources  Do  I  Need? 

A  business  needs  three  general  resources  to  interchange  data 
electronically:  computer  hardware,  computer  software,  and  com¬ 
munications  capability.  Equally  important  is  the  way  those 
resources  are  configured.  A  company  or  DoD  activity  can  use 
a  mainframe  computer  to  communicate  directly  with  a  trading 
partner  using  an  industry-accepted  standard.  It  can  purchase 
translation  software  from  a  software  vendor  and  then  integrate 
that  software  into  an  existing  data  processing  system.  The 
software  translates  the  user’s  unique  data  formats  into  standard 
data  formats  before  they  are  electronically  transmitted.  Trans¬ 
lation  software  designed  for  mainframe  computers  costs  from 
$20,000  to  $200,000.  Very  few  private-sector  companies  choose 
to  develop  their  own  software. 
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Even  with  a  mainframe  computer,  communications  are  typically 
handled  over  telephone  lines.  A  company,  for  instance,  will  dial 
one  of  its  largest  vendors,  connect  to  its  computer,  and  transmit 
electronic  purchase  orders. 

Alternatively,  a  company  or  DoD  activity  may  elect  to  operate 
in  a  front-end  environment  in  which  the  host  computer  —  the 
mainframe  —  simply  transfers  a  file  of  purchase  orders  (or  other 
digital  business  documents)  to  a  front-end  computer  —  a  micro¬ 
computer  on  which  the  EDI  translation  software  resides.  The 
microcomputer  then  translates  the  user-unique  format  into  the 
standard  format  and  transmits  the  standard-formatted  file  to  the 
trading  partners.  Many  companies  prefer  this  front-end  environ¬ 
ment  for  two  reasons:  its  start-up  costs  are  a  modest  $10,000 
to  $15,000  and  the  data  in  the  host  computer  are  secure  since 
trading  partners  have  access  to  the  front-end  microcomputer  only. 

Although  the  front-end  microcomputer  environment  offers  a  low- 
cost  entry  into  EDI  and  a  high  degree  of  flexibility,  it  also  has 
some  disadvantages.  One  disadvantage  is  that  as  a  company’s 
EDI  programs  expand,  the  processing  capability  of  a  microcom¬ 
puter  can  become  overwhelmed.  Another  disadvantage  —  and 
one  common  to  direct  use  of  a  mainframe  computer  —  is  the 
need  to  communicate  directly  with  trading  partners.  Each  com¬ 
munications  session  involves  dialing,  connecting,  and  transmitting 
to  the  trading  partner’s  computer,  a  relatively  easy  task  if  a 
company  has  only  a  handful  of  trading  partners.  However,  if  the 
EDI  program  encompasses  many  trading  partners,  the  scheduling 
of  communications  sessions  can  become  a  real  problem. 

1 .4.5  What  Third-Party  Services  Are  Available? 

Another  alternative  operating  concept  uses  the  ”  electronic  mail¬ 
boxes”  provided  by  third-party,  or  value-added  network  (VAN), 
services.  A  company  can  transmit  all  of  its  purchase  orders, 
invoices,  shipping,  technical  specifications,  or  other  electronic 
transactions  to  the  VAN  in  a  single  communications  session  and 
thus  solve  the  communications  scheduling  problem.  The  stan¬ 
dards  are  structured  such  that  the  VAN  can  deposit  transactions 
into  each  trading  partner’s  “electronic  mailbox.”  The  trading 
partners  can  then  dial  the  VAN,  receive  their  transactions,  and 
deposit  new  transactions  for  others,  all  in  one  communications 
session.  VANs  also  provide  other  services.  Some,  for  instance, 
offer  translations;  others  provide  special  processing  such  as 
editing  transmissions  for  content  or  nuiling  multiple  copies  of  a 
transmission  for  distribution  to  numerous  trading  partners. 
Clearly,  using  the  VAN  as  a  vehicle  for  communicating  with 
business  trading  partners  is  the  configuration  most  preferred  by 
U.S.  companies. 

1 .4.6  What  Are  the  Benefits? 

The  benefits  of  EDI  extend  far  beyond  a  decrease  in  paper: 
more  accurate  records,  lower  data  entry  costs,  elimination  of 
mailing  costs,  decreased  paper  handling,  greater  customer  satis¬ 
faction,  reduced  inventory,  better  cash  management,  reduced 
order  time,  and  more  accurate  information  for  management. 
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1 .4.6.1  More  Accurate  Records 

Initially,  when  information  is  entered  into  a  computer  system, 
say,  by  keypunching,  the  software  edits  it  to  ensure  accuracy. 
Editing  will  typically  give  an  error  message  if,  for  example,  the 
account  number  or  part  number  is  not  valid  or  if  the  price  is 
incorrect.  With  the  massive  amounts  of  data  being  exchanged 
today,  some  errors  are  going  to  occur  when  a  manual  entry 
process  is  used.  Such  data  entry  errors  can  be  very  costly.  If 
an  invoice  is  authorized  for  a  $1,000  payment  instead  of  a 
$100  payment  or  if  an  order  is  filled  to  ship  100  items  instead 
of  10  items,  time  and  money  are  wasted  trying  to  discover  and 
correct  the  error.  Even  if  98  percent  of  the  information  entered 
manually  is  accurate,  the  2  percent  that  contains  errors  can  be 
embarrassing  (e.g.,  a  customer’s  name  may  be  misspelled)  or 
costly  (e.g.,  undercharging)  a  customer. 

EDI  ensures  greater  information  accuracy  by  exchanging  data 
directly  between  computer  systems.  A  major  freight  carrier 
indicated  that  one  EDI  client  transmitted  600,000  freight  bills 
electronically  in  a  span  of  18  months  with  absolutely  no  errors. 
For  that  client,  the  elimination  of  errors  alone  paid  for  the  cost 
of  developing  an  EDI  system. 

1 .4.6.2  Lower  Data  Entry  Cost 

Nothing  is  more  inefficient  than  manually  keyboarding  data  from 
one  computer  printout  into  another  computer  system.  EDI 
eliminates  the  need  to  reenter  such  data.  With  most  communica¬ 
tions  packages  today,  information  can  be  uploaded  and 
downloaded  (i.e.,  passed  to  another  computer  program  without 
being  rekeyboarded)  directly.  EDI  installations  report  that  they 
have  transmitted  10,000  documents  (i.e.,  invoices)  accurately 
within  minutes  and  processed  them  immediately  witti  no  human 
intervention. 

1 .4.6.3  Reduced  Inventory 

Timely  processing  of  information  allows  suppliers  to  know  what 
material  to  ship  and  when  to  ship  it  instead  of  having  to  estimate 
when  and  where  the  material  is  needed.  One  company  was  able 
to  reduce  its  inventory  by  $167  million  in  the  first  18  months  it 
was  involved  in  EDI.  That  company  not  only  saved  the  cost  of 
carrying  that  inventory  but  was  also  able  to  reduce  the  amount 
of  outside  warehouse  space  it  needed. 

Inventory  reductions  through  EDI  are  not  limited  to  the  user; 
suppliers,  too,  have  been  able  to  reduce  their  inventories.  Com¬ 
panies  using  EDI  can  transmit  accurate  and  timely  information 
on  the  exact  time  they  need  supplies  rather  than  having  all 
supplies  for  the  month  being  due  on  the  first  day  of  the  month. 
Suppliers  have  learned  to  trust  the  EDI  information  transmitted 
and  plan  the  receipt  of  the  material  and  production  runs  based 
on  true  need,  not  guesswork  or  urgent  phone  calls.  A  manufac¬ 
turer  and  its  suppliers,  for  example,  have  been  able  to  reduce 
inventories  by  as  much  as  80  percent. 
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1 .4.6.4  Decreased  Mailing  Costs  and  Paper  Handling 

Mailing  an  order  is  costly  and  inefficient.  When  the  cost  of 
typing  the  order,  addressing  the  envelope,  and  inserting  the  order 
into  the  envelope  are  added  to  the  cost  of  postage,  a  single  order 
can  cost  $5  or  more.  When  many  orders  are  sent  or  received 
each  year,  the  costs  accumulate.  Sending  those  orders  in  an 
overnight  package  adds  another  $5  to  $10.  Many  EDI  installa¬ 
tions  have  been  justified  merely  by  the  savings  in  mailing  and 
handling  costs. 

When  the  information  from  and  to  each  trading  partner  is  trans¬ 
mitted  electronically,  the  mounds  of  paper  that  were  previously 
moved  from  one  department  to  the  next  in  the  company  can  be 
eliminated.  Information  on  an  order  or  an  invoice  is  stored  in 
the  computer,  ready  to  be  processed  into  the  order  entry  system 
or  accounts  receivable  system.  Instead  of  filing  a  piece  of  paper, 
a  computer  image  can  be  processed  directly  onto  microfilm  or 
other  media,  thus  meeting  the  standard  audit  requirement  of 
maintaining  a  copy  for  record  purposes. 

Many  private-sector  firms  use  the  remittance/payment  advice  to 
electronically  apply  cash  to  an  invoice  number.  One  check  may 
pay  thousands  of  invoices.  To  post  the  payment  information  to 
a  record  manually  may  take  hours,  whereas  with  EDI,  it  can  be 
done  in  minutes  and  without  error. 

1 .4.6.5  Greater  "Customer  Satisfaction” 

With  an  efficient  EDI  system,  an  order  can  be  received, 
processed,  and  shipped  almost  as  quickly  as  it  can  be  transmitted. 
Many  companies  use  EDI  to  buy  such  material  as  office  supplies, 
sandpaper,  work  gloves,  and  other  items  not  used  directly  in 
their  production  process.  They  send  the  order  electronically  and 
the  goods  are  shipped  immediately.  Many  freight  carriers  let 
their  customers  look  at  the  carrier’s  computer  infonnation  to  help 
locate  information  about  a  customer’s  shipments.  This  adds  to 
the  customer  satisfaction  by  enabling  shipments  to  be  located 
more  quickly  and  efficiently. 

1 .4.6.6  Reduction  in  Order  Time 

Often,  in  submitting  and  receiving  an  order,  as  much  as  a  week 
or  more  is  consumed  by  nuiling  and  handling  time.  One-day 
handling  of  paper  on  both  ends  and  2  to  3  days  in  the  postal 
system  means  that  the  use  of  EDI  can  eliminate  almost  a  full 
week  of  order  time.  With  EDI,  we  can  in  many  cases  order 
goods  and  have  them  shipped  the  same  day. 

1 .4.6.7  Better  Cash  Management 

By  taking  advantage  of  EDI,  companies  can  control  the  purchase 
of  the  right  material  at  the  right  time  and  thus  better  plan  their 
cash  disbursements.  When  EDI  is  used  to  transmit  an  invoice 
or  an  advanced  shipping  notice  for  use  in  an  evaluated  receipt 
settlement  (ERS)  system,  the  invoice  is  handled  with  consistency 
and  no  guesswork  is  needed  to  know  when  it  will  be  paid.  That 
consistency  allows  for  much  more  efficient  cash  management. 
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With  the  use  of  electronic  funds  transfer  (EFT),  both  parties  can 
better  plan  the  use  of  the  funds. 

A  paper  payment  check  may  arrive  anywhere  from  2  to  4  days 
after  it  is  mailed  —  that  time  is  referred  to  as  the  float.  With 
EFT,  the  money  arrives  on  the  day  on  which  it  is  planned  to 
arrive.  With  a  consistent  flow  of  money,  the  use  of  that  money 
can  be  more  efficiently  planned. 

The  issue  of  float  —  the  time  from  issuance  of  a  check  to  the 
time  it  is  deposited  in  an  account  —  however,  needs  to  be 
neutralized.  In  today's  paper  world,  the  real  terms  are  not  “net 
10  days”  as  they  appear  but  rather  “net  10  days  plus  float,”  or 
the  time  the  check  is  in  the  mail  and  has  not  been  deposited. 
The  money  leaves  one  bank  account  and  actually  enters  another 
in  13  days  rather  than  the  10  days  that  the  payment  terms  state. 
With  EDI,  payment  terms  need  to  reflect  Ae  “real”  terms  — 
and  everyone  wins  because  both  parties  can  better  plan  when 
money  will  enter  and  leave  an  account. 

1 .4.6.8  More  Accurate  Information  for  Decisions 

The  availability  of  accurate  information  permits  an  organization 
to  accelerate  its  ability  to  identify  problem  areas  and  to  highlight 
areas  with  the  greatest  potential  for  efficiency  in^>rovement  or 
cost  reduction.  Better  information  about  shipping  charges,  inven¬ 
tories,  sales  orders,  shipment  dates,  invoice  amounts,  or  cash  flow 
is  the  keystone  for  more  efficient  operation.  Continuous 
knowledge  cf  the  exact  whereabouts  of  inbound  freight,  for 
example,  enables  more  accurate  scheduling  of  the  receiving  dock 
and  in  many  cases  better  scheduling  of  the  production  floor. 

1 .4.7  How  Do  I  Get  Started? 

Now  that  we  know  what  EDI  is,  what  resources  are  needed  for 
EDI,  and  what  some  of  the  good  business  reasons  for  using  EDI 
are,  the  next  step  is,  “How  do  I  get  started  sending  messages 
electronically?” 

You  need  to  start  by  reviewing  your  internal  systems.  Each 
ANSI  standard  or  convention  is  introduced  with  the  following 
words; 

Tbit  tundard  wtt  developed  with  the  intent  that  uaen  need 
not  reprogram  their  internal  data  proceuing  lyatema.  The 
ftandard  it  ttnictured  to  allow  computer  prognmt  to  trantlate 
iitfemal  formatt  to  the  data  transmitaion  tundard,  and  con- 
vertely,  dau  received  for  procetting  to  internal  tyttemt. 

Software  to  trantlate  daU  to  and  from  the  tUndard'a  format 
may  be  uaer  developed  or  commercially  purchated. 

If  you  can  process  the  information  in  paper  form  today,  you 
should  have  an  easy  time  converting  to  EDI.  You  may  discover 
some  efficiencies  can  be  realized  by  changing  your  internal 
system,  but  you  do  not  have  to  change  it  to  conduct  business 
electronically.  You  may  also  consider  undertaking  some  or  all 
of  the  steps  outlined  in  the  following  subsections. 
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1. 4.7.1  Education 

A  seminar  on  EDI  will  expose  you  to  what  others  are  doing  and 
help  you  “sell”  the  idea  of  EDI  in  your  company  or  activity. 
Many  educational  programs  are  available  from  which  to  choose: 
the  Automotive  Industry  Action  Group,  the  National  Industrial 
Transportation  League,  the  American  Trucking  Association,  the 
Electronic  Data  Interchange  Association,  ASC  X12,  and  VANs, 
to  name  just  a  few.  Attend  one;  it  is  a  chance  to  talk  to  others 
about  EDI. 

1 .4.7.2  Establish  a  Project  Team 

The  private  sector  has  found  that  the  team  approach  to  EDI  is 
highly  successful.  All  the  disciplines  of  the  company  need  to 
be  represented  on  the  team,  and  a  project  leader  needs  to  be 
selected  to  help  coordinate  the  meetings  and  the  EDI  projects. 

Some  EDI  projects  may  involve  only  selected  departments,  but 
others  will  cross  several  disciplines.  Share  the  information  at 
the  meetings  and  provide  the  minutes  of  those  meetings  to  as 
many  people  as  possible.  They  will  help  others  learn  what  you 
are  doing. 

Involve  your  financial  people  as  early  as  possible.  Once  they 
are  tuned-in  to  EDI,  they  may  become  your  strongest  supporters. 

Discuss  the  various  aspects  of  EDI  at  your  project  team  meetings. 
What  types  of  EDI  do  you  want  to  do?  What  standards  could 
you  use?  Would  a  third-party  network  help?  What  resources 
do  you  need?  What  standards  are  already  being  used  in  your 
company  or  industry? 

Use  these  meetings  to  help  educate  your  organization  about  EDI. 
Bring  in  outside  experts,  use  internal  experts,  but  gather  the  facts 
and  communicate  die  results. 

1 .4.7.3  Develop  a  Plan 

A  corporate  strategy  should  evolve  from  these  discussions.  Each 
discipline  should  submit  a  summary  of  projects  to  which  it  will 
apply  EDI,  and  those  projects  should  be  officially  included  within 
the  discipline’s  budget  plans.  If  any  individual  project  has  no 
payback,  that  project  may  need  to  be  reevaluated.  EDI  must  be 
applied  for  good  business  reasons,  not  just  for  the  sake  of 
applying  EDI. 

Internal  systems  may  contain  all  the  information  you  need  to 
send  efficient  EDI  messages,  but  some  information  may  be  in 
the  wrong  files.  When  getting  started,  do  not  try  to  make  too 
many  changes  at  one  time.  If  the  appropriate  information  can 
be  printed  on  a  piece  of  paper,  it  can  also  be  translated  for  EDI. 

If  a  piece  of  information  does  not  translate  easily,  do  not 
immediately  revise  your  system.  Perhaps  a  note  (NTE)  segment 
will  get  you  by  until  sufficient  business  reasons  exist  for  up^ting 
your  internal  programs.  If  the  existing  codes  do  not  meet  your 
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circumstances,  submit  a  change  request  through  your  activity  to 
the  ASC  X12  Data  Interchange  Standards  Association  (DISA). 

Your  plans  should  be  discussed  with  all  disciplines  involved, 
including  systems,  accounting,  auditing,  legal,  and  transportation. 

Reach  consensus  on  your  long-term  goals  and  establish  individual 
tasks  that  move  you  toward  those  goals.  Assign  to  individuals 
the  responsibilities  to  complete  the  tasks. 

Keep  in  mind  that  successes  are  needed  to  keep  the  team 
motivated;  publish  all  successes.  The  more  you  make  the  entire 
organization  aware  of  the  successes,  the  more  others  will  give 
their  support. 

1 .4.7.4  Conduct  a  System  Analysis 

Your  goals  should  include  developing  answers  to  the  following 
questions; 

•  What  documents  will  be  sent,  using  what  standard  formats? 

•  Who  are  your  trading  partners  and  in  what  order  will  they 
be  brought  onboard? 

•  Which  trading  partner  will  you  select  for  the  pilot  test  of 
your  EDI  system? 

•  When  will  systems  resources  be  available? 

•  Do  you  develop  your  own  communications  network  or  select 
a  third-party  network? 

•  Do  you  purchase  software  or  write  your  own? 

Study  the  alternatives  discussed  in  our  earlier  Section  1.4.4  on 
what  resources  are  needed. 

The  EDI  systems  entail  some  communications  costs.  Who  as¬ 
sumes  those  costs  varies  from  industry  to  industry  and  company 
to  company.  When  compared  with  the  overall  savings  produced 
by  EDI,  these  costs  often  are  insignificant.  In  the  automotive 
industry,  the  supplier  typically  pays  for  sending  and  receiving 
EDI  (i.e.,  phone  charges  or  third-party  network  charges).  In 
other  industries,  the  sender  of  a  message  may  pay  the  costs  or 
the  sender  and  receiver  may  split  them  evenly.  Review  your 
industry  practice  and  establish  an  organizational  position  that  best 
fits  your  needs. 

1 .4.7.5  Coordinate  Your  Plans 

Let  your  trading  partners  know  what  you  will  be  doing  well  in 
advance.  They  will  need  to  make  some  of  the  same  changes 
you  are  making.  Inquire  about  their  level  of  EDI  readiness;  they 
may  be  ready  and  just  waiting  for  you  to  say  something. 
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Train  as  many  people  in  your  organization  as  you  can  on  what 
you  are  doing  and  why.  Training  always  pays  off  in  the  long 
term.  The  more  people  that  understand  the  process,  the  better 
chance  you  have  for  success. 

Be  sure  to  let  your  purchasing  department  know  what  you  are 
doing.  In  many  cases,  they  will  be  the  first  ones  your  trading 
partners  will  call  with  questions.  Make  sure  they  know  who  can 
answer  additional  questions. 

1 .4.7.6  Choose  Your  Partners  Wisely 

In  choosing  a  trading  partner  for  a  pilot  test  of  your  EDI  system, 
select  someone  you  may  have  met  at  an  EDI  conference  who  is 
already  experienced  or  ask  your  managers  whether  any  suppliers 
or  customers  have  expressed  interest. 

In  the  pilot  test,  you  can  learn  what  processes,  procedures,  and 
operations  need  to  be  worked  out  —  something  you  may  have 
left  out  or  did  not  fully  understand. 

The  more  your  trading  partners  know  about  what  you  will  be 
doing,  the  happier  they  will  be  about  using  EDI  with  you.  Let 
them  know  what  you  want  to  do  and  when  you  want  them  to  do 
It.  Remember  when  you  were  being  asked  to  support  EDI? 
Give  your  trading  partners  60  to  90  days  notice  or  more.  They 
will  need  to  make  many  of  the  same  evaluations  you  did  when 
you  started  your  EDI  project. 

Carefully  select  a  group  of  trading  partners  that  will  benefit  the 
most  from  your  EDI  approach.  If  the  EDI  project  will  not 
benefit  the  trading  partners,  they  may  choose  not  to  participate. 
Do  not  forget  that  the  selling  job  you  had  to  do  in  your  own 
organization  must  now  be  done  in  your  trading  partner’s.  Each 
partner  needs  to  allocate  resources  for  EDI. 

The  easiest  way  to  determine  which  trading  partners  are  most 
willing  to  participate  in  EDI  with  you  is  the  same  way  you 
determined  what  documents  to  use  first:  volume.  The  trading 
partner  that  sends  you  the  largest  number  of  invoice  line  items 
is  the  one  that  will  gain  the  most  from  your  electronic  invoice 
or  ERS  system.  The  one  that  sells  you  the  largest  number  of 
parts  is  the  one  to  gain  the  most  from  an  electronic  material 
release  or  schedule. 

1 .4.7.7  Expand  Your  Project  Through  Conferences 

Twenty  to  forty  suppliers  at  each  conference  is  a  good  number. 
The  conference  will  give  them  a  chance  to  discuss  the  issues 
with  you  in  more  detail.  Provide  them  with  a  handout  detailing 
all  the  information  they  will  need  to  support  your  EDI  project 
and  ask  for  their  feedback. 

You  must  be  ready  for  some  setbacks.  Perhaps  you  forgot  to 
inform  a  key  individual.  Perhaps  a  key  element  in  the  plan  is 
not  ready  or  has  not  tested  successfully.  Focus  attention  on  the 
problem  and  find  the  solution. 
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1.5  HOW  TO  USE  THE  IMPLEMENTATION 
GUIDELINES 

The  main  topics  and  structures  of  this  document  conform  to  the 
EDI  Implementation  Reference  Manual  Guidelines  document  that 
was  developed  by  a  task  group  of  the  subcommittee  on  education 
and  implementation  of  the  ASC  XI 2.  The  purpose  of  having 
agreed-upon  topics  and  structure  is  to  facilitate  reference  by  the 
many  industry  and  DoD  persoimel  who  are  involved  in  im¬ 
plementing  the  uniform  standards  for  electronic  interchange  of 
business  transactions. 

The  guidelines  are  divided  into  chapters.  Chapters  1  through  9, 
found  in  Volume  I,  contain  both  functional  and  technical 
guideline  information  that  is  relatively  stable.  Chapter  10,  found 
in  Volume  11,  contains  the  specific  conventions  for  using  ASC 
X12  standards;  those  standards  are  subject  to  periodic  updating 
and  will  be  expanded  as  new  conventions  are  added. 

1.5.1  Guidelines,  Standards,  and  Conventions 

The  terms  guidelines,  standards,  and  conventions  are  used 
throughout  the  document  and  are  defined  as  follows: 

•  Guidelines  are  instructions  on  the  use  of  EDI.  They  provide 
additional  information  to  assist  in  conducting  EDI. 
Guidelines  are  intended  to  provide  assistance  and  should  not 
be  your  sole  source  of  information. 

•  Standards  are  the  technical  documentation  aj^roved  by 
ASC  X12;  specifically,  transaction  sets,  segments,  data  ele¬ 
ments,  code  sets,  and  interchange  control  structure.  Stan¬ 
dards  provide  the  structure  for  each  ASC  X12  document. 

•  Conventions  are  the  common  practices  and/or  interpretations 
of  the  use  of  ASC  X12  standards.  Conventions  define  what 
is  included  in  a  specific  implementation  of  an  ASC  X12 
standard. 

1.5. 1.1  Who  Develops  the  Conventions? 

Conventions  result  from  a  joint  effort  between  business,  techni¬ 
cal,  and  an  EDI  ASC  X12  standards  experts.  The  business  data 
requirement  is  defined,  a  transaction  set  is  selected,  and  the  data 
requirement  is  then  identified  with  data  elements  in  the  transac¬ 
tion  set.  A  convention  is  usually  developed  before  any  computer 
systems  development  work  and  serves  as  a  design  document  when 
the  development  process  begins. 

1.5. 1.2  Why  Use  a  Convention? 

To  create  an  ASC  X12  transaction,  a  user  must  know  the  data 
requirements,  understand  the  ASC  X12  standard,  and  be  able  to 
use  that  information  to  develop  an  interface  program  between  the 
computer  application  and  the  ASC  X12  translator.  The  necessary 
information  to  perform  this  task  is  contained  in  the  convention 
document.  Users  who  follow  the  convention  will  create  a  trans¬ 
action  set  that  all  DoD  users  understand. 
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1.5. 1.3  Who  Needs  a  Convention? 

System  analysts  and  applicaiton  programmers  who  plan  to  create 
or  read  ASC  X12  transactions  should  use  a  convention  to  aid  in 
interface  software  design.  The  convention  will  help  the  program¬ 
mer  and  analyst  identify  where  their  application  data  requirement 
should  be  carried  in  an  ASC  X12  transaction  set. 

1.5. 1.4  Do  I  Develop  a  Convention? 

Conventions  already  exist  for  some  of  the  most  common  business 
practices.  Copies  of  existing  conventions  can  be  acquired  through 
your  organization’s  EDI  coordinator  at  the  start  of  an  EDI 
project.  If  you  End  no  conventions  for  the  business  practice 
you  are  about  to  implement,  your  EDI  coordinator  should  contact 
the  DoD  Executive  Agent  for  EDI.  See  Chapter  S,  Maintenance, 
for  the  point  of  contact. 

1.5.2  Page  Numbering 

Chapters  1  through  9  and  Sections  10.1  through  10.6  use  the 
following  page-numbering  scheme: 

Chapter  number;  page  number:  for  example, 
page  5.0.1  is  the  first  page  of  Chapter  5.0. 

Chapter  10.7  is  composed  of  multiple  sections  (one  for  each 
transaction  set)  and  is  numbered  to  reflect  the  transaction  set 
number  and  version. 

Transaction  set  no.;  version  control  no.;  page 
no.:  for  example,  810.002002.19  is  the 

nineteenth  page  of  the  section  on  transaction  set 
810,  version  002,  release  002. 

This  permits  the  maintenance  of  multiple  versions  of  the  same 
transaction  set  during  a  transition  period. 

1.5.3  Documentation  of  industry  Conventions 

Conventions  are  adopted  from,  and  are  intended  to  be  in  con¬ 
formance  with,  ANSI  ASC  X12  standards  or  ASC  X12  Draft 
Standards  for  Trial  Use  (DSTU). 

Figure  1.5-1  is  an  extract  from  Chapter  10,  Section  7  and 
provides  an  example  of  a  transaction  set.  The  transaction  set 
deEnes  informaEon  of  business  or  strategic  signiEcance  and 
consists  of  a  transaction  set  header  segment,  one  or  more  data 
segments  in  a  speciEed  order,  and  a  transaction  set  trailer 
segment.  The  actual  ASC  X12  standard  as  it  appears  in  the 
ofEcial  ASC  X12  standards  manual  is  presented  on  die  right  side 
of  the  page.  This  standard  also  includes  both  syntax  notes  and 
comments.  The  speciEc  industry  usage  designator  and  notes  are 
presented  on  the  left  side  of  the  page. 

The  designation  “use”  appears  in  the  left  column  if  the  industry 
uses  the  specific  segment  and  remains  blank  if  the  industry  does 
not. 
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Figure  1.3*1  Example  of  a  Transaction  Set 
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1 . 5 .3 . 1  T ransaction  Set  Hierarchy 

The  transaction  set  hierarchy  shows  which  segments  may  be  used 
in  a  transaction  set  and  the  proper  sequence  of  those  elements 
within  the  transaction  set. 

A  segment  directory  contains  the  definitions  and  formats  used 
by  the  industry  in  the  construction  of  each  particular  transaction 
set.  This  segment-by-segment  description  permits  the  reader  to 
examine  the  specific  usage  of  each  data  element  and  segment  in 
the  transaction  set. 

Terms  and  definitions 

•  Level 

The  level  indicates  whether  the  segment  is  used  at  the  Header 
(Table  1),  Detail  (Table  2),  or  Summary  (Table  3)  level  of 
the  transaction. 

•  Segment  Requirement  Designator  (Reg  Des) 

The  following  definitions  are  for  use  in  interpreting  the 
segment  requirement  designators  in  the  industry-specific  Seg¬ 
ment  Directory  section  of  the  guideline. 

>  Mandatory 

Mandatory  segments  are  defmed  by  ASC  X12. 

>  Optional 

The  use  of  optional  segments  is  determined  by  the  trading 
partners. 

>  Required 

A  required  segment  is  considered  optional  under 
ASC  X12  rules  but  is  required  by  industry  decision. 

>  Recommended 

Recommended  segments  are  considered  optional  under 
ASC  X12  rules  and  by  the  industry,  but  the  industry 
recommends  their  use  to  facilitate  EDI.  Most  companies 
in  the  industry  are  expected  to  use  this  segment. 

1 .5.3.2  Transaction  Set  Segment 

Figure  1.5-2  is  an  example  of  a  transaction  set  segment. 

Industry  usage  is  specified  on  the  left  side  of  the  page.  Between 
the  two  sides  of  the  page  is  a  narrow  colunm  for  designating  an 
industry  variation  from  the  ASC  X12  standard.  The  **  <  ”  symbol 
is  used  to  draw  attention  to  the  deviation. 

For  identifier  (ID)  —  type  data  elements,  acceptable  code  values 
are  listed  on  the  right  side  of  the  page  under  the  definitions  of 
the  element.  When  ID  elements  are  not  used  by  the  industry, 
definitions  of  the  data  do  not  appear.  Large  or  repeated  code 
lists  may  be  included  in  a  separate  section  and  referenced. 
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Industry  notes  may  appear  on  the  left  side  of  the  page  or  after 
the  last  data  element  of  the  segment. 

The  following  definitions  are  for  use  in  interpreting  the  data 
element  requirement  designators  in  the  industry-specific  segment 
directory  section  of  the  guideline.  For  ASC  X12  usage,  see  the 
definitions  in  X12.6  Application  Control  Structure. 

•  Mandatory 

Mandatory  data  elements  are  defined  by  ASC  X12. 

•  Optional 

Optional  data  elements  are  used  at  the  discretion  of  the 
sending  party  or  are  based  upon  mutual  agreement  between 
trading  partners. 

•  Required 

Required  data  elements  are  considered  optional  under 
ASC  X12  rules,  but  are  required  by  industry  decision. 

•  Recommended 

Recommended  data  elements  are  considered  optional  under 
ASC  X12  rules  and  by  the  industry,  but  the  industry  recom¬ 
mends  their  use  to  facilitate  EDI.  Most  companies  in  the 
industry  are  expected  to  use  this  data  element. 

•  Hot  Used 

“Not  Used”  data  elements  are  those  that  the  industry  does 
not  use. 

•  Conditional 

Conditional  data  elements  depend  on  the  presence  of  other 
data  elements  in  the  transaction  set. 
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2.0  BUSINESS  ISSUES 


This  chapter  provides  guidelines  for  the  successful  implementa¬ 
tion  of  ASC  X12  EDI  standards  in  your  organization.  It 
addresses  transaction  timing,  modes  of  operation,  security, 
recovery,  and  audit  considerations. 

2.1  IMPLEMENTATION  CONSIDERATIONS 

EDI  is  not  an  insignificant  task.  It  is  intended  to  change  the 
way  you  do  business  and  will  affect  many  areas  of  your 
organization’s  support  and  operational  mission.  Top  management 
must  be  involved  in  the  approval  phases  of  the  project  to  ensure 
the  availability  of  adequate  funding  and  personnel  for  the  project 
and  support  for  the  affected  organizational  areas.  Requirements 
for  projects  may  vary  from  one  organization  to  another;  very 
large  projects  should  use  life  cycle  management  (LCM),  while 
smaller  projects  may  only  need  one  or  two  full-time  personnel. 
In  either  case,  you  should  adhere  to  the  following  general  rules 
for  a  successful  project. 

•  EDI  is  a  solution  to  a  business  problem  and  must  be  treated 
as  a  business  issue.  You  need  a  plan  that  clearly  defines 
the  scope  of  the  project  and  methods  for  carrying  out  an 
organized  effort  to  achieve  specific  business  objectives. 

•  Do  not  deviate  firom  the  published  standards.  Deviations 
will  require  you  to  customize  your  system  and  will  increase 
cost  in  the  long  run  as  trading  partners  are  added  and 
standards  change. 

•  Make  the  transition  to  a  full  production  system  only  after 
your  system  has  proved  itself. 

•  Conduct  integrated  system  testing  to  ensure  the  existing 
systems  you  are  interfacing  with  are  operating  properly. 

•  Do  not  forget  internal  controls  and  the  need  to  provide  an 
audit  trail  of  EDI  activity. 

•  To  obtain  the  highest  payback  from  your  EDI  system, 
integrate  it  into  your  internal  systems  and  business  proce¬ 
dures. 

2.1.1  Staffing  Requirements 

EDI  projects  differ  from  traditional  internal  automation  projects 
in  that  planning,  development,  and  implementation  tasks  must  be 
performed  by  organizations  outside  DoD’s  authority  and  control, 
which  adds  an  additicmal  level  of  complexity  to  the  project 
manager’s  tasks.  To  offset  this  control  problem,  a  senior  EDI 
manager  should  be  appointed  at  a  grade  level  that  will  facilitate 
coordination  at  the  corporate  level. 


Implementing  EDI  projects  involves  many  people  in  a  variety  of 
roles.  Such  projects  require  a  great  deal  of  coordination  between 
the  functional  managers  and  the  automation  managers.  At  a 
minimum,  the  EDI  project  should  have  the  following  staff: 

•  Senior  manager 

•  Project  manager 

•  Functional  coordinator  (for  each  business  area  impacted) 

•  Technical  coordinator 

•  EDI  coordinator 

•  Contract  administrator. 

For  a  small  EDI  system,  some  of  those  staff  positions  may  be 
combined.  For  larger  systems,  all  personnel  may  be  required 
full  time. 

During  the  project,  it  may  be  necessary  to  establish  support 
groups  to  assist  the  project  team.  The  following  groups  are 
suggested; 

•  Operations  Group  -  includes  functional  coordinators  to 
develop  the  business  plan. 

•  Liaison  Group  -  includes  technical  and  functional  coor¬ 
dinators  to  manage  standards  and  procedures  with  organiza¬ 
tions  outside  DoD. 

•  Technical  Group  -  includes  analysts  with  a  detailed 
knowledge  of  the  interfacing  systems,  communications,  com¬ 
puter  operations,  and  operating  system  software. 

Again,  for  small  projects,  the  operations  of  these  groups  may  be 
combined. 

2.1.2  Implementation  Checklist 

The  following  16  subsections  specify  actions  that  you  should  take 
when  implementing  an  EDI  program. 

2.1 .2.1  Obtain  a  Commitment  From  Management 

Identify  key  management  personnel  from  aU  organizations  that 
will  be  affected  by  the  implementation.  Each  identified  organiza¬ 
tion  should  be  included  in  the  analysis,  development,  testing,  and 
implementation. 

2. 1.2.2  Establish  a  Plan 

Use  project  management  tools  to  develop  a  work  plan,  identifying 
as  many  tasks  as  possible.  Provide  resource  estimates  and  es¬ 
timated  completion  times  where  possible.  Prepare  a  milestone 
schedule  and  identify  potential  savings.  Brief  management  on 
the  plan. 
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2. 1.2.3  Establish  a  Project  Team  and  Define  ResponsibiiKies 
Construct  a  responsibility  matrix.  List  the  tasks  to  be  performed 
across  the  page  (vertical  component)  and  the  team  members  down 
the  page  (horizontal  component).  Determine  whether  you  have 
enough  people  to  implement  the  EDI  program.  Also  see  wdiether 
certain  tasl^  will  require  someone  not  previously  identified.  You 
must  be  specific  about  deliverables  expected  from  each  task. 

2. 1.2.4  Establish  EDI  Contacts 

Contact  organizations  that  have  implemented  ASC  X12  EDI 
standards.  Industry  associations  and  network  providers  are  a 
good  source  of  information. 

2. 1.2.5  Review  Internal  Systems  and  Operational  Procedures 

You  must  conduct  a  system  analysis  of  the  processes  that  create 
the  business  data  you  need  and  document  the  flow.  Work-place 
procedures  must  be  reviewed  and  documented. 

2.1 .2.6  Obtain  Appropriate  Reference  Materials 

Obtain  copies  of  the  ANSI  ASC  X12  publications,  related  train¬ 
ing  materials,  and  industry  implementation  guidelines.  You  will 
need  access  to  data  dictionaries  and  documents  that  define 
functional  codes. 

2. 1.2.7  Survey  Potential  Trading  Partners 

You  will  need  to  know  the  level  of  experience  of  your  trading 
partners,  resources  they  have  available,  whether  their  systems 
are  automated,  and  what  kind  of  communication  system  they  are 
using. 

2. 1.2.8  Review  the  Business  Data  You  Wish  to  Exchange 
Thoroughly  review  or  map  your  business  data  against  the  DoD 
conventions  of  ANSI  ASC  X12.  By  so  doing  you  will  be  able 
to  determine  whether  your  internal  system  contains  all  the 
required/mandatory  data  elements.  You  should  identify  opticmal 
data  elements  and  discuss  them  with  your  trading  partners. 

2. 1.2.9  Develop  an  Overall  Design 

Using  &e  information  you  have  collected,  prepare  a  detailed 
system  integration  plan  that  identifies  the  following  items: 

•  General  narrative 

•  Functional  description 

•  Data  requirements  and  data  flows 

•  System  specifications 

•  Program  specifications 

•  User  procedures 

•  Computer  operation  procedures. 
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2.1.2.10  Develop  a  Communication  Plan 

Discuss  this  plan  with  your  trading  partners.  You  should  develop 
this  plan  early  since  it  will  influence  other  decisions  such  as 
maintaining  connection,  coordinating  the  polling  schedules, 
providing  audit  reports,  and  sharing  costs. 

2.1 .2.1 1  Code  and  Test  the  Interface  from  the  Internal  Systems 
to  the  Translation  Software 

The  EDI  translation  software  configuration  is  dependent  upon 
your  system  design.  In  all  but  in-house-developed  software, 
translation  software  must  interface  with  your  internal  application 
systems  and  communication  system. 

2.1.2.12  Install  Translation  Software 

Translation  software  must  be  configured  to  run  in  your  system 
environment  (unless  you  are  using  a  network-based  translation). 
Tables  must  be  updated  and  modified  to  support  your  applica¬ 
tions. 

2.1.2.13  Install  Communications 

No  matter  which  communication  alternative  you  have  chosen, 
some  installation  task  will  be  required. 

2.1.2.14  Conduct  an  Integrated  Test  of  Ail  Components 

Conduct  an  integrated  test  of  all  components  to  verify  that  the 
system  can  perform  the  following  tasks: 


•  Generate  data  from  the  internal  system 

•  Translate  the  data  into  ANSI  ASC  X12  format 

•  Assemble  and  transmit  the  ANSI  ASC  X12  formatted  data 

•  Receive  transmissions 

•  Translate  the  ANSI  ASC  X12  format  to  the  internal  system 
format 

•  Generate  and  send  an  acknowledgment. 

2.1 .2.1 5  Conduct  a  System  Test  With  Your  Trading  Partner 
Conduct  extensive  system  testing  prior  to  actual  production. 
Parallel  testing  with  the  old  system  to  validate  the  transmissions 
should  occur  for  a  predetermined  time  period.  Develop  an 
agreement  document  that  includes  all  participants  in  the  project 
and  have  everyone  sign  it  before  production  begins.  Make  sure 
all  contract  agreements  have  been  signed. 

2.1.2.16  Determine  Initial  Operational  Capability  (IOC) 

Initial  production  should  be  limited  to  one  or  two  trading  partners 
and  one  or  two  different  transaction  sets.  You  should  predeter¬ 
mine  a  time  period  for  IOC  that  can  be  used  to  validate 
assumptions  about  cost  savings  and  to  adjust  your  implementation 
plans  prior  to  expanding  to  other  trading  partners. 
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2.2  TIMING  OF  TRANSACTIONS 

The  timing  of  transactions  is  critical  to  the  smooth  flow  of  work 
and  directly  affects  the  network  transmission  cost  (off-hours  cost 
less).  The  data  flow  requirement  has  been  documented  during 
the  analysis  phase  of  the  project  and  should  be  described  in 
enough  detail  to  optimize  data  needs  and  transmission  cost. 

Business  issues  must  also  be  considered.  You  must  address  such 
issues  as  when  to  release  the  EFT  (or  other  payment  method) 
and  when  to  time  stamp  a  response  to  a  request  for  quotation. 
These  issues  are  discussed  in  Section  3.4,  Trading  Partner 
Agreements  (TPAs)  and  in  Section  7.1,  DoD  Business  Models. 

2.3  MODES  OF  OPERATION 

You  can  operate  your  EDI  system  in  two  modes:  test  and 
production.  When  the  interchange  becomes  production  is  a 
decision  that  must  be  agreed  upon  by  all  participants.  Prior  to 
that  time,  all  interchanges  are  coded  as  “T”  (test  data)  in  the 
interchange  control  header.  Production  interchanges  are  coded 


2.4  SECURITY 

DoD  Components  must  employ  risk  management  techniques  to 
determine  the  appropriate  security  controls  needed  to  protect 
specific  data  and  systems.  Optional  tools  and  techniques  for 
implementation  of  security  and  authentication  provided  by 
ASC  X12  may  be  used  consistent  with  the  security  risk.  For 
example,  the  interchange  control  header  (ISA)  segment  offers  die 
capability  of  password  protection. 

Security  precautions  taken  to  protect  EDI  data  and  transmissions 
should  be  at  least  as  good  as  those  currently  employed  for  the 
paper  exchange. 

The  security  of  unclassiried/sensitive  systems  is  a  concern  and  the 
Office  of  the  ASD  (P&L)  has  established  a  program  tided  “Protec¬ 
tion  of  Logistics  Unclassified/Sensitive  Systems”  to  address  the 
issues.  The  results  of  a  prototype  project  to  test  and  assess 
commercially  available  and  affordable  products  demonstrated  c<hi- 
vincingly  that  protection  can  be  achieved  by  combining  the  speed 
of  a  Data  Encryption  Standard  (DES)  with  the  advantages  of 
Public  Key  Cryptography  (PKC)  for  key  exchange.  The  PLUS 
program  seeks  to  provide  low-cost  procedures  that  will  misure  the 
protection  and  authentication  of  EDI  transmissions  from  anyindiere 
in  the  world,  using  public  telecommunication  carriers,  in  the  clear 
or  encrypted.  In  addition,  the  PLUS  program  will  provide  for 
digital  signatures,  including  nonrepudiation  attributes  \riiere  re¬ 
quired.  Hie  security  afforded  by  developing  technology  will 
support  compliance  with  the  Computer  Security  Act  of  1987 
(P.L.  100-235).  A  joint  task  group  (Production  and  Logistics 
Task  Group  for  Data  Protection)  has  been  established  to  provide 
guidance  for  the  implementation  of  the  PLUS  program  initiatives. 
The  ASC  X12  Security  task  group  is  also  defining  how  PKC  will 


be  specified  in  the  X12.42  Cryptographic  Message  and 
X12.S8  Security  Structures  Standards. 

2.5  RECOVERY  PROCEDURES 

DoD  Components  should  establish  back-up  procedures  to  provide 
for  retransmitting  EDI  messages. 

•  Back-up  and  recovery  procedures  should  be  available  for  use 
if  computer  systems  or  transmission  fails. 

•  A  maximum  number  of  attempts  or  retransmissions  following 
a  text  transmission  error  should  be  established,  to  minimize 
communications  costs  for  bad  connections. 

•  For  real-time  transactions,  such  as  the  advance  ship  notice 
and  shipping  schedule,  a  minimal  24-to-48  hour  immediate- 
access  backup  should  be  available. 

•  Batch  transactions,  such  as  those  used  for  the  purchase  orders 
and  invoice,  require  a  l-to-2-week  minimum-access  backup. 

•  Some  type  of  archive  storage  in  which  the  data  are  backed 
up  and  stored  on  a  more  permanent  basis  should  be  available. 
The  permanent  archives  and  supporting  system  should  pro¬ 
vide  for  recovering  a  specific  EDI  message  from  the  archives 
and  retransmitting  it. 

The  back-up  and  recovery  system  must  be  thoroughly  documented 
to  allow  anyone  with  the  proper  authority  to  access  the  system 
to  retransmit  data. 

The  Fimctional  Acknowledgment  (997)  Transaction  Set  can  be  used 
to  provide  a  level  of  automation  in  the  back-up  and  recovery  area. 
If  the  EDI  system  expects  to  receive  a  functional  acknowledgment 
for  every  transaction  it  sends,  the  EDI  message  should  be  available 
for  retransmission  until  a  functional  acknowledgment  corresponding 
to  a  specific  EDI  message  is  received.  Otace  that  fimctional 
acknowledgment  is  received,  the  original  EDI  message  can  be 
archived  regardless  of  the  normal  archive  timing. 

The  system  could  be  designed  to  provide  a  degree  of  flexibility. 
The  use  of  functional  acknowledgments  could  then  vary  on  the 
basis  of  business  requirements.  It  may  be  appropriate  to 
send/receive  functional  acknowledgments  by  trading  partner, 
transaction,  some  combination  of  the  two,  or  some  other  variable 
unique  to  your  EDI  requirements. 

If  a  third-party  network  is  used,  additional  costs  will  be  assessed 
to  send  and  receive  functional  acknowledgments.  Your  level  of 
risk  must  be  known  when  considering  whether  the  additional 
costs  of  including  a  flexible  functional  acknowledgment  com¬ 
ponent  in  your  EDI  system  and  sending  and  receiving  functional 
acknowledgments  are  justified. 
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2.5.1  Recovery  Procedure  Considerations 

You  should  establish  recovery  procedures  to  allow  for  controlled 
management  of  unusual  telecommunications  problems.  The  fol¬ 
lowing  are  some  potential  problems  that  should  be  managed  by 
the  EDI  system: 

•  A  trading  partner’s  computer  that  won’t  answer  when  your 
computer  calls  to  pick  up  or  deliver  EDI  messages. 

•  A  bad  connection  that  causes  continuous  or  excessive  num¬ 
bers  of  retransmissions. 

•  How  to  notify  someone  when  a  predetermined  threshold 
number  of  errors  are  encountered. 

2.5.2  Disaster  Recovery  Considerations 

Disaster  recovery  becomes  correspondingly  critical  as  the  amount 
of  business  that  is  conducted  through  EDI  increases.  Consider 
the  consequences  if  you  were  suddenly  unable  to  telecommunicate 
for  some  period  of  time  —  say,  a  week. 

You  should  not  assume  that  you  can  hill  back  on  a  paper-based 
system.  Your  trading  partners  may  not  be  able  to  quicldy  switch 
from  EDI  messages  to  mailing  their  business  transactions  to  you. 
You  may  not  have  immediate  access  to  the  resources  in  your 
organization  needed  to  process  paper  transactions. 

Develop  a  plan  to  deal  with  extreme  problems,  such  as  a  total 
loss  of  a  data  center  or  computer  system  or  a  loss  of  a 
telecommunications  switch  station  servicing  your  area. 

2.6  AUDIT  CONSIDERATIONS 

The  elimination  of  paper  document  processing  through  the  intro¬ 
duction  of  ASC  X12  EDI  standards  requires  an  evaluation  of 
your  existing  internal  control  processes  and  procedures.  Without 
a  signed  document  and  paper  audit  trail,  how  can  you  determine 
whether  a  transaction  is  accurate,  valid,  and  approved? 

This  problem  is  not  a  new  one.  All  application  and  telecom¬ 
munication  systems  have  been  addressing  this  type  of  problem 
for  many  years  and  the  same  elements  of  control  apply  in  EDI 
as  they  do  in  other  automated  systems. 

Controls  are  applied  to  ensure  the  following: 

•  Confidentiality  ~  Only  authorized  persons  have  access  to  die 
data« 

•  Integrity  -  Data  accuracy. 

•  Authenticity  -  These  are  actual  or  real  transactions  that 
belong  to  you. 
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Controls  can  be  applied  at  different  levels  and  directed  to  specific 
threats.  These  can  be  categorized  as  follows: 

•  Passive  Threats  -  unauthorized  persons  have  access  to  and 
can  use  information  they  have  no  right  to. 

•  Active  Threats  -  unauthorized  persons  received  information 
they  have  no  right  to  and  made  changes  to  the  data  to  their 
advantage  before  passing  the  information  on  for  processing 
by  the  rightful  owners. 

•  Human  Errors  -  errors  that  occur  throughout  the  cycle  of 
any  information  flow  when  human  intervention  is  required. 

2.6.1  Confidentiality 

Some  examples  of  how  you  can  ensure  confidentiality  of  your 
EDI  transmissions  are  as  follows: 

•  Encryption  -  a  method  of  logically  scrambling  the  EDI 
information  with  an  encryption  key  and  giving  the  key  only 
to  persons  who  have  a  right  to  that  information.  The  key 
is  an  electronic  code  for  this  procedure. 

•  Passwords  -  used  to  control  browsing  of  files.  Passwords 
should  be  changed  often  for  maximum  effect. 

•  Stand-alone  computers  -  used  in  place  of  a  company  main 
computer  to  interface  with  other  companies.  The  EDI  infor¬ 
mation  can  then  be  uploaded  to  the  main  computer  for  use  in 
applications. 

•  Local  delivery  -  a  control  by  which  goods  purchased  at  a 
location  can  be  delivered  only  to  that  location. 

2.6.2  integrity 

Integrity  of  the  information  is  extremely  important  in  EDI 
because  the  same  data  are  used  many  times  in  the  interchange 
process.  EDI  is  at  its  best  when  data  are  validated  at  the  front 
end  of  the  process  so  they  are  correct  for  the  rest  of  the  steps 
in  the  process. 

•  Senders  of  EDI  data  should  satisfy  themselves  as  well  as  the 
receivers  that  they  have  imposed  adequate  controls  to  ensure 
that  data  at  the  beginning  of  the  process  have  a  good  chance 
of  being  correct. 

•  VANs  provide  additional  controls,  such  as  checking  for  alpha 
characters  in  a  numeric  field  and  looking  for  the  existence 
of  critical  data  fields. 

•  ANSI  X12  standards  provide  controls,  such  as  the  functional 
acknowledgments  and  various  record  and  segment  counts. 

•  Conversion  tables  must  be  updated  to  ensure  adequate  con¬ 
version  to  the  user’s  codes.  If  one  party  in  the  interchange 
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receives  someone  else’s  information  in  error,  a  large  number 
of  mismatches  will  probably  occur  on  normally  valid  table 
look-ups. 

•  By  creating  mechanized  trend  or  exception  reports  which 
compare  current  data  with  those  of  a  past  period,  you  can 
detect  significant  variances. 

2.6.3  Authenticity 

The  parties  to  data  interchange  can  be  certain  that  the  transactions 

being  received  are  the  “real  thing”  in  several  ways: 

•  By  using  controlled,  authorized,  trading-partner  codes.  This 
process  and  other  areas  of  agreement  should  be  clearly 
spelled  out  in  the  signed  trading  partner  agreement.  Trading 
partner  agreements  are  an  important  tool  in  the  control  and 
accountability  of  EDI. 

•  By  comparing  user  codes  to  a  list  of  valid  codes  before 
transactions  are  accepted. 

•  By  using  a  password  to  provide  user  codes  a  double  level 
of  protection. 

•  By  retaining  the  file  that  contained  the  data  separately  once 
data  has  been  transmitted  to  prevent  a  retransmission  of  the 
same  data.  These  files  may  be  needed  for  backup  if  a  valid 
retransmission  is  required. 
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3.0  LEGAL  CONSIDERATIONS 


This  chapter  explains  the  legal  implications  of  implementing  EDI. 
In  it,  record  keeping,  authentication,  TPAs,  third-party  service 
agreements,  laws,  rules,  and  regulations  are  discussed. 

3.1  INTRODUCTION 

The  use  of  EDI  is  on  the  verge  of  an  explosion.  At  first  blush, 
it  might  appear  to  the  uninitiated  that  computer-to-computer 
transfer  of  business  and  logistics  documentation  in  a  machine- 
readable  form  will  never  fit  within  the  strictures  of  the  Defense 
Department’s  laws  and  regulations.  Nonetheless,  EDI  is  now 
being  used  in  the  Department  of  Defense  and  its  use  will  grow 
exponentially  in  the  near  term. 

The  development  of  the  law  regarding  EDI  when  compared  with 
the  development  of  computer  technology  is  quite  sluggish  even 
in  the  private  sector.  It  is  even  slower  developing  in  the  public 
sector.  That  growth  is  not  unusual,  however,  since  the  law 
develops  relatively  late  when  compared  to  the  rapid  growth  of 
technology  in  most  fields.  The  precise  legal  status  of  EDI 
transactions  is  somewhat  uncertain.  Yet  those  uncertainties  have 
not  posed  a  significant  obstacle  to  adoption  of  EDI  in  private 
industry.  Similarly,  they  should  not  do  so  in  the  Defense 
Department. 

We  do  not  suggest  that  EDI  systems  be  implemented  within  DoD 
with  legal  impunity.  On  the  contrary,  legal  counsel  should 
become  part  of  the  EDI  team  from  the  conceptual,  or  planning, 
phase.  Most  current  law  on  paper  transactions  can  be  transported 
into  EDI  transactions  with  litde  risk.  Courts  and  Boards  are 
very  comfortable  in  handling  disputes  involving  traditional  paper 
agreements.  Contracting  officers  and  audit  and  financial  officials 
are  similarly  comfortable  with  paper  docummts  and  are  naturally 
reluctant  to  step  into  the  somewhat  uncharted  waters  of  electronic 
transmissions.  Legal  counsel,  with  a  positive  attitude  toward 
improving  productivity  in  an  era  of  shrinking  defense  budgets, 
can  provide  invaluable  service  in  implementing  EDI  efficiently 
while  minimizing  the  legal  risks  to  DoD.  EDI  is  a  tool  that  can 
efficiently  perform  the  millions  of  daily  DoD  transactions  and 
one  that  can  save  scarce  resources  and  improve  service  at  the 
same  time. 

This  chapter  outlines  guidance  to  DoD  acquisition  and  logistics 
personnel  on  the  legal  considerations  in  implementing  EDI.  It 
deals  with  pertinent  Federal  statutes,  the  Federal  Acquisition 
Regulation  (FAR),  and  the  DoD  FAR  Supplement  (DFARS). 
The  attitude  of  modem  day  Courts  and  Boar^  toward  computer¬ 
generated  documents  is  discussed.  Record  keeping,  TPAs  and 
third-party  network  agreements,  and  associated  legal  issues  are 
also  discussed. 
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3.2  FEDERAL  LAW  AND  REGULATIONS 

Literature  in  trade  papers  and  legal  journals  is  proliferating 
rapidly  in  terms  of  EDI  legal  issues,  especially  in  private 
industry.  Much  discussion  is  centered  around  lae  legal  require¬ 
ments  of  the  Uniform  Commercial  Code  dealing  with  commercial 
law  between  private  contracting  parties.  Much  of  the  discussion 
treats  the  requirement  for  the  sale  of  goods  exceeding  a  certain 
amount,  typically  those  sales  exceeding  $S00.  Such  sales  are 
required  to  be  in  writing  and  signed  by  the  party  to  be  bound 
(Uniform  Commercial  Code,  Section  2-201).  Further  discussion 
invariably  involves  the  signature  or  authentication  requirement. 

Federal  officials  should  be  familiar  with  these  critical,  timely 
issues  but  should  be  mindful  that  the  Uniform  Commercial  Code 
is  not  Federal  law  and,  therefore,  it  is  not  legally  binding  in 
Federal  acquisitions.  Many  times  in  the  absence  of  Federal 
judicial  precedent,  attorneys  argue  the  Code’s  principles  for 
persuasion,  but  judges  on  the  Federal  Courts  and  ^ards  feel  no 
obligation  to  accept  the  argument. 

The  DoD  contracting  officers  may  not  conclude  that  EDI  transac¬ 
tions  may  be  accomplished  in  an  unfettered  fashion.  In  fact.  Title 
31  of  the  United  States  Code,  Section  ISOl,  specifies  certain  writing 
requirements  before  public  money  shall  become  an  obligation  of  die 
United  States.  It  states: 

An  amount  ihall  be  recorded  as  an  obligation  of  the  United 

Statea  Government  only  when  supported  by  documentary 

evidence  of  - 

(1)  A  binding  agreement  between  agencies  and  another 
person  ...  that  is  - 

(a)  In  writing,  in  a  way  and  form,  and  for  a  purpose 
authorized  by  law;  and 

(b)  Executed  before  the  end  of  the  period  of  availability  for 
obligation  of  the  appropriation  or  fond  used  for  specific 
goods  to  be  delivered,  real  property  to  be  bought  or 
leased,  or  work  or  Krvice  to  be  provided; 

« 

(2)  A  loan  agreement  showing  the  amount  and  terma  of 
repayment; 

(3)  An  order  required  by  law  to  be  placed  with  an  agency; 

(4)  An  order  issued  under  a  law  authorizing  purchases 
without  advertising  - 

(a)  When  necessary  because  of  a  public  exigency; 

(b)  For  perishable  subsistence  supplies;  or 

(c)  Within  specific  monetary  limits; 
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(5)  A  grant  or  nibsidy  payable  - 


(a)  From  appropriationt  made  for  payment  of,  or  contribu¬ 
tions  to,  amounts  required  to  be  paid  in  specific  amounts 
fixed  by  law  or  under  formulas  prescribed  by  law;  ... 

(6)  A  liability  that  may  result  from  pending  litigation; 

(7)  Employment  or  services  of  person  or  expenses  of  travel 
under  law; 

(8)  Services  provided  by  public  utilities;  or 

(9)  Other  legal  liability  of  the  Government  against  an  avail¬ 
able  appropriation  or  fiind. 

Does  this  mean,  for  example,  that  all  DoD  contracts  must  be  in 
writing  and  in  hard  copy  to  be  legally  enforceable?  Some 
Federal  financial  officials  have  espoused  the  position  that  this 
law  constitutes  a  recording  statute  binding  only  on  the  financial 
community  and  not  on  the  procurement  community.  That  view 
seems  to  beg  the  question.  As  a  matter  of  fact,  in  an  important 
Federal  Court  case  involving  a  similar  law  (predecessor  statute). 
Government  attorneys  urged  upon  the  Court  that  “the  statute  is 
simply  a  recording  statute  to  facilitate  auditing  and  has  no  affect 
on  government  contracts  with  private  parties.”  The  Court 
rejected  the  argiunent  and  foimd  an  oral  contract  unenforceable 
(United  States  v.  American  Renaissance  Lines,  Incorporated, 
494  Federal  Reporter,  2nd  series,  1059). 

In  that  case,  the  Court  was  dealing  with  a  purported  oral  contract. 
We  cannot  overemphasize  that  when  EDI  transactions  are  properly 
executed,  they  are  much  more  than  an  oral  contract.  EDI 
transactions  can  possess  whatever  built-in  reliability  and  security 
their  importance  and  size  warrants.  Therefore,  Courts  and 
Boards  should  not  be  reluctant  to  enforce  them. 

The  above-mentioned  statute  (31  USC§1S01)  requires  different 
levels  of  documentation:  most  notable  are  small  purchases  and 
other  purchases  that  do  not  require  advertising.  Most  EDI 
purchasing  systems  in  DoD  rely  upon  one  or  the  other  of  Uiese 
exceptions  for  their  legality.  DoD  could  conceivably  purchase 
as  much  as  90  percent  of  its  supplies  under  these  exceptirais. 

This  practice  of  DoD  limiting  pilot  and  test  EDI  programs  to 
small  purchases  should  not  be  construed  as  an  implicit  concession 
that  EDI  transactions  per  se  do  not  comply  with  the  “in-writing” 
requirement  of  the  statute.  A  convincing  argument  can  be  made 
that  a  carefully  drafted  TPA  plus  the  EDI  documents  themselves 
constitute  a  writing  and  can  be  executed  so  as  to  comply  literally 
with  the  statute.  (TPAs  are  discussed  subsequently  in  this 
chapter.) 
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In  addition  to  the  Federal  law  mentioned  above,  the  FAR  must 
be  considered.  FAR  2.101  defines  a  contract  as: 

A  mutually  binding  legal  relationahip  obligating  the  teller  to 
fumidi  the  tuppliei  or  lervicet  (including  conitniclioo)  and 
the  buyer  to  pay  for  them.  It  includes  all  types  of  commit¬ 
ments  that  obligate  the  Govenunent  to  an  expenditure  of 
appropriated  funds  and  that,  except  as  otherwise  authorized, 

•re  in  writing. 

There  are  authorized  exceptions.  FAR  Part  13,  for  example, 
authorizes  oral  orders  for  calls  against  blanket  purchase  agree¬ 
ments.  DFARS  208.40S-2  (S-70)  states  that  oral  orders  not  in 
excess  of  small  purchase  thresholds  are  authorized  for  orders 
from  multiple-award  schedules.  Oral  orders  issued  against  in¬ 
definite  delivery  contracts  must  be  confirmed  in  writing  although 
written  confirmation  may  be  a  letter  and  not  a  contractual 
document.  [FAR  16.506  (b)]. 

As  a  general  rule.  Government  acquisition  regulations  require 
written  contracts  to  be  signed.  FAR  1.601  states  “Contracts 
may  be  entered  into  and  signed  on  behalf  of  the  Government 
only  by  contracting  officers.”  Of  course,  that  rule  refers  to 
those  transactions  not  falling  within  the  exceptions  qiecified 
above. 

FAR  4.101  states  the  following: 

Coniracting  officer’s  ttgnature;  (a)  Only  contracting  officen 
■hall  fign  contncu  on  behalf  of  the  United  States.  The 
contracting  officer's  name  shall  be  typed,  stanqied,  or  printed 
on  the  contract.  The  coniracting  officer  normally  signs  after 
it  has  been  signed  by  the  contractor.  The  contracting  officer 
dull  ensure  that  the  signeT(s)  have  authority  to  bind  the 
coitiracts. 

Modem  technology  makes  possible  in  EDI  transactions  electronic 
message  authentication  to  ensure  the  transaction  is  executed  by 
someone  having  authority.  The  question  of  “a  writing”  and 
“signature”  when  viewed  against  31  USC§1S01,  FAR  2.101,  and 
4.101  is  ambiguous  with  respect  to  EDI.  Certainly,  the  desire 
of  Courts  and  Boards  to  uphold  the  intent  of  the  parties  will 
prevail.  If  the  intent  of  the  parties  is  to  form  a  binding 
agreement  and  the  computer  equipment  and  techniques  are  reli¬ 
able,  the  agreement  should  be  legally  binding. 

With  respect  to  electronic  signatures  for  the  statutory  requirement 
of  certifying  public  vouchers  under  31  USC§332S  and  §3528, 
the  law  is  clearer  and  further  developed.  The  General  Accoimt- 
ing  Office  (GAO)  has  stated  the  following: 

The  essence  of  certificstion  is  the  assurance  or  representation 
that  some  act  has  or  has  not  been  done,  or  some  event 
occurred,  or  some  legal  formality  has  been  complied  with. 
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In  Memorandum  B-104S90,  September  12,  1951,  the  Comptroller 
General  stated  the  following: 

While  cenificationi  of  the  natuie  here  involved  ordinarily  are 
acconplidied  by  handwritten  aignaturea,  the  obvioua  burden 
that  would  reault  by  tequirinf  aame  afforda  a  baaia  for  the 
adoption  of  an  alternate  meana,  if  olherwiae  proper.  In  thia 
regard,  the  couita  have  held  that  a  aignature  conaiata  of  the 
writing  of  one’a  name  and  of  the  intention  that  it  authenticate 
the  inatrument,  and,  therefore,  any  aymbol  adopted  aa  one’a 
aignature  when  affixed  with  hia  knowledge  and  conaent  ia  a 
bindiog  and  legal  aignature  when  the  atatute  requirea  an 
inatrument  to  be  aigned.  Citing  13  Comp.  Dec.  749;  1  Op. 

Any.  Gen.  670. 


Of  course,  the  GAO  has  long  recognized  facsimile  signatures  and 
machine-made  signatures  as  legally  binding.  The  GAO  con¬ 
cluded  in  Memorandum  B-21603S,  September  20,  1984,  that 

an  appropriate  aymbol  may  be  adopted  by  a  certifying  officer 
aa  hia  aignature  for  the  purpoae  of  voucher  certification.  The 
aignature  aervea  aa  a  guarantee  of  the  authenticity  of  the 
certificate.  See  alao  Blacks  Law  Dictionary. 

Today,  EDI  transactions  can  include  an  electronic  message 
authenticaticm  code  that  ensures  the  certification  was  nuule  by 
someone  with  the  requisite  authority  to  certify. 

In  any  event.  Courts  uniformly  hold  that  with  respect  to  signa¬ 
tures,  the  operative  condition  is  the  “intent”  to  use  a  marking 
as  one’s  signature  rather  than  the  marking  itself.  It  must  be 
shown  that  the  nuker  of  the  symbolic  signature  intei^  to  be 
legally  bound.  The  prevailing  legal  view  today  respecting 
electronic  signatures  sets  forth  at  least  two  requirements  before 
gaining  legal  efficacy;  (1)  electronic  signatures  must  be  adopted 
as  a  person’s  “unique  code  signature”  and  (2)  appropriate  security 
measures  must  exist  to  ensure  that  the  “code”  cannot  be  accessed 
by  unauthorized  individuals.  This  latter  requirement  must  not 
be  minimized. 

The  General  Services  Administration  (GSA)  had  little  difficulty 
in  accommodating  EDI  in  transportation  activities  by  regulatory 
change.  In  amending  41  Code  of  Federal  Regulations  (CFR), 
Part  101-41,  the  GSA,  without  resorting  to  a  statutory  change, 
clarified  the  “writing”  and  “signature”  requirements  regarding 
bills  of  lading,  audit,  and  payment.  The  GSA  regulations  state: 

Bectronic  Data  Interchange,  (EDI)  means  the  electronic 
tranamitsion  of  the  information  in  lieu  of  the  creation  of  a 
paper  document.  Also,  ‘signature’  in  the  case  of  EDI 
transmission,  means  a  discrete  authenticating  code  intended 
to  bind  parties  to  the  terms  and  conditions  of  a  contract. 

[Author’s  Note:  While  this  guide  was  in  printing,  GAO  issued 
a  memorandum  opinion  that  should  advance  the  development 
of  EDI,  and  to  a  greater  extent,  clarify  the  question  of  whether 
EDI  documents  satisfy  the  requirements  of  31  USC§1S01.  The 
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following  is  some  significant  language  taken  from  GAO 
Memorandum  B-238449,  Electronic  Contracting,  19  June  1991. 

EDI  U  the  electronic  exchange  of  buiinesf  information  be¬ 
tween  partiei,  uaually  vU  a  computer,  using  an  agreed  upon 
format.  EDI  is  being  used  to  transmit  shipping  notices, 
invoices,  bid  requests,  bid  quotes  and  other  messages. 

Electronic  contracting  is  the  use  of  EDI  technologies  to  create 
contractual  obligations.  EDI  allows  the  patties  to  examine 
the  contract,  usually  on  video  monitors,  but  sometimes  on 
paper  facsimiles,  store  it  electronically  (for  example  on 
magnetic  tapes,  on  discs  or  in  special  memory  chips),  aiul 
recall  it  from  storage  to  review  it  on  video  monitors, 
reproduce  it  on  paper  or  even  mail  it  via  electronic  means. 

Using  EDI  technologies,  it  is  possible  for  an  agency  to 
contract  in  a  fiaction  of  the  time  that  it  now  takes.  The 
‘paperless*  nature  of  the  technology,  however,  has  raised 
the  question  of  whether  electronic  contracts  constitute  obliga¬ 
tions  which  may  be  recorded  against  the  government. 

••• 


To  constitute  a  valid  obligation  under  section  1501  (a)(1)(A), 
a  contract  must  be  supported  by  documentary  evidence  *in 
wrilirig.*  Some  have  questioned  whether  EDI,  because  of 
the  paperless  nature  of  the  techrtology,  fulfills  this  require- 
mettf.  We  conclude  that  it  does. 

For  the  purpose  of  interpreting  federal  statmes,  *writing*  is 
defined  to  include  ‘printing  and  typewriting  and  reproductions 
of  visual  symbols  by  photographing,  multigraphing, 
mimeographing,  manifolding,  or  otherwise.*  1  U.S.C.  S  i 
(emphasis  added).  Although  the  temu  of  contracts  formed 
usirtg  EDI  ate  stored  in  a  different  manner  than  those  of 
paper  and  ink  contracts,  they  ultimately  take  the  form  of 
visual  symbols.  We  believe  that  it  is  sensible  to  itterpret 
federal  law  in  a  manner  to  accottutK>date  technological  ad¬ 
vancements  unless  the  law  by  its  own  terms  expressly 
precludes  such  an  interpretation,  or  sound  policy  reasons  exist 
to  do  otherwise.  It  is  evident  that  EDI  technology  had  not 
been  conceived  nor,  probably,  was  even  anticipated  at  the 
time  section  1501  and  the  statutory  definition  of  ‘writirtg* 

(sic)  were  enacted.  Nevertheless,  we  believe  that,  given  the 
legislative  history  of  section  1501  and  the  expansive  definition 
of  writing,  section  1501  and  1  U.S.C.  }  1  encompass  EDI 
technology. 

Department  of  Defense  personnel  who  are  engaged  in  implementing 
EDI  in  any  program  should  study  the  GAO  opinion  thoroughly.] 

3.3  RECORD  KEEPING  AND 
EVIDENTIARY  MATTERS 

Record  keeping  regulations  and  the  Federal  Rules  of  Evidence  have 
a  far  better  track  record  in  keeping  pace  with  computer  technology 
than  have  the  contract  formation  regulations.  For  instance,  the 
Federal  Rules  of  Evidence  are  used  in  Courts  and  Boards  involving 
Federal  questions  including  DoD  contract  dilutes.  The  Federal 
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Rules  take  a  modernistic  approach  to  udiat  evidtaice  may  be  admitted 
into  evidence  in  litigation.  They  should  not  be  viewed,  dierefore, 
as  obstacles  to  using  EDI  in  DoD  transactions. 

The  requirement  for  record  keeping  is  clear  and  must  comply 
with  Chapter  31,  Title  44  of  the  United  States  Code,  Records 
Management  by  Federal  Agencies.  It  requires  Federal  agencies 
to  “establish  and  maintain  an  active,  continuing  program  for  the 
economical  and  efficient  management  of  the  records  of  the 
agency,”  and  “provide  for  effective  controls  over  the  creation 
and  maintenance  of  records  in  the  conduct  of  current  agency 
business”  (44  USC53102). 

At  44  USC§3301,  Federal  records  are  said  to  include  all 

books,  psperi,  maps,  photographs,  machine-readable 
materials  or  other  documentaiy  materials,  regardless  of  physi¬ 
cal  form  or  characteristics,  made  or  received  by  ao  agency 
of  the  U.S.  Government*  (emphasis  supplied). 

That  language  would  seem  to  accommodate  and  encourage  die 
use  of  modem  information  technology,  including  machine- 
readable  EDI  dociunents. 

The  Federal  Rules  of  Evidence  are  even  more  accommodating. 
Rule  1001(1)  states  in  part: 

Writings  and  Recotdmgs  ...  consist  of  letters,  words,  or 
nundters,  or  their  equivalem,  set  down  by  *...  magnetic 
impulse,  mechanical  or  electronic  recording  or  other  data’ 
compilation  (emphasis  supplied). 

In  adopting  EDI,  DoD  will  necessarily  have  to  maintain  a  host 
of  files,  which  are  nothing  more  than  electronically  inqirinted 
codes  on  magnetized  surfaces.  These  are  really  electronic  or 
magnetic  filing  systems.  DoD  records  maintenance  personnel 
should  not,  therefore,  be  overly  concerned  with  substituting  EDI 
documents  for  hard  copy  since  it  is  obvious  that  these  electronic 
files  are  considered  “writing  or  recordings”  under  the  law.  The 
rules  of  evidence  are  no  different  for  electronically  filed  records 
than  for  paper  records. 

Furthermore,  in  the  Hnal  analysis,  any  regimen  in  record  keeping 
should  be  built  with  a  view  toward  what  a  Court  will  accept  as 
evidence  should  a  dispute  or  controversy  arise.  Judges  use  the 
“best  evidence  rule”  when  admitting  documents  into  evidence, 
which  means  they  want  the  original  document.  In  this  regard 
Federal  Rule  of  Evidence  1001(3)  states  in  part: 

An  'original*  of  a  writing  or  recording  is  the  writing  or 
recording  itself  or  any  counterpart  intended  to  have  the  same 
effect  by  a  person  executing  it  ....  If  data  are  stored  in  a 
computer  or  similar  device,  any  printout  or  other  output 
readable  by  sight,  diown  to  reflect  the  data  accurately,  is  an 
'original.* 


Title  28  USC§1731  provides  for  the  admissibility  of  copies  or 
reproductions  of  original  records  kept  in  the  re^ar  course  of 
business.  These  evidentiary  rules  should  give  comfort  to  DoD 
personnel  desiring  to  implement  EDI  transactions.  There  are 
many  more  accommodating  rules.  This  guidance  is  not  intended 
as  an  exhaustive  treatment.  Legal  advice  is  critical  throughout 
the  design  and  implementation  of  any  EDI  system. 

Recently,  the  FAR  was  amended  to  clarify  the  issue  of  electronic 
records  (Federal  Acquisition  Circular  84-53),  for  DoD  contrac¬ 
tors  and  trading  partners. 

(d)  If  Uie  information  deicribed  in  paragraph  (a)  of  thia 
lection  ii  maintained  on  a  computer,  contractor!  ihall 
retain  the  computer  data  on  a  reliable  medium  for  the 
time  period!  prewribed.  Contractor!  may  tranifer  com¬ 
puter  data  in  machine  readable  form  from  one  reliable 
computer  medium  to  another.  Contractor!’  computer 
data  retention  and  tranafer  procedure!  ahall  maintain  the 
integrity,  reliability,  and  aecurity  of  the  original  com¬ 
puter  data.  Contractor!  ahall  alao  retain  an  audit  trail 
deacribiqg  the  data  tranafer.  For  the  record  retention 
time  period!  preacribed,  contractor!  ahall  not  deMroy, 
diacard,  delete,  or  write  over  auch  computer  data. 

In  May  1990,  the  National  Archives  and  Records  Administration 
(NARA)  issued  final  regulations  on  Electronic  Records  Manage¬ 
ment.  Following  is  an  extract: 

§1234.24  Judicial  uae  of  electtoidc  record!. 

Electronic  record!  may  be  admitted  in  evidence  to  l^ederil 
court!  for  uae  in  court  proceeding!  [Federal  Rule!  of 
Evidence  803(8)]  if  iruatworthinea!  ia  eatabliahed  by 
thoroughly  documenting  the  recordkeeping  ayatem’a  operation 
and  the  control!  impoaed  upon  it.  Agenciea  diould  imple¬ 
ment  the  following  procedure!  to  enhance  the  legal  admia- 
aibility  of  electronic  record!. 

(a)  Document  that  aimilar  kinda  of  record!  generated  and 
ittned  electronically  ate  created  by  the  aame  proceaaei 
each  time  and  have  a  atandardized  retrieval  approach. 

(b)  Subatantiate  that  aecurity  procedure!  prevent  un¬ 
authorized  addition,  modification  or  deletion  of  a  record 
and  enaure  ayatem  protection  againat  auch  problem!  aa 
power  interruption!. 

(c)  Identify  the  electronic  media  on  which  record!  are  atored 
throughout  their  life  cycle,  the  maximum  time  apan  that 
recorda  remain  on  each  atornge  medium,  and  the  NARA- 
approved  diapoaition  of  all  recorda. 

(d)  Coordinate  all  of  the  above  with  legal  counael  and  aenior 
IRM  and  record!  management  ataff. 

3.4  FREEDOM  OF  INFORMATION  ACT 

The  Department  of  Defense  implements  the  Freedom  of  Infor¬ 
mation  Act  (FOIA)  at  32  CFR  286.  In  a  recent  amendment,  the 
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regulations  contain,  for  the  first  time,  guidance  relative  to  the 
release  to  die  public  of  electronic  data  under  the  Act  (55  Fed. 
Reg.  53104,  26  December  1990). 

The  DoD  policy  is  to  conduct  its  activities  openly  and  provide 
the  public  with  a  maximum  amount  of  accurate  and  timely 
information  on  its  activities,  consistent  always  with  national 
security  and  the  legitimate  interest  of  the  American  petqile.  A 
DoD  record  requested  by  a  member  of  the  public  who  follows 
rules  established  by  proper  DoD  authority  can  be  withheld  only 
when  it  is  exempt  from  mandatory  public  disclosure  under  the 
FOIA. 

An  agency  record  is  defined  as 

...  the  producu  of  data  compilation,  wch  aa  all  booki, 
papen,  mapi,  and  photograpbi,  machine  readable  materiali 
or  oUier  documentary  materiali,  rejardleat  of  phytical  form 
or  characteriitici,  made  or  received  by  an  agency  ...  in 
connection  with  the  transaction  of  public  butiness  and  in 
DoD’s  posietnon  and  control  at  the  time  the  FOIA  retpiest 
is  made. 

When  reaching  a  decision  on  whether  to  release  information  to 
the  public,  DoD  officials  must  distinguish  between  whether  the 
requested  information  is  a  record  (under  the  law)  or  is  other 
valuable  property.  This  distinction  is  especially  important  when 
the  request  might  entail  intellectual  property. 

Administrative  tools  that  are  used  to  create,  store,  and  retrieve 
records  are  not  normally  considered  records.  Included  among 
those  tools  are  items  such  as  computer  software,  source  code, 
object  code,  listings  of  source  and  object  code,  etc.  However, 
they  do  not  include  the  underlying  data  that  are  processed  and 
produced  by  the  software.  In  some  instances,  such  data  may  be 
actually  stored  with  the  software. 

Sometimes  computer  software  may,  by  necessity,  be  treated  as 
an  agency  record  and  processed  under  the  FOIA  procedures. 
This  should  occur  rather  infrequently;  it  may  occur  in  a  situation 
in  which  the  data  are  embedded  within  die  software  and  cannot 
be  extracted  without  the  software.  In  other  instances,  die 
software  may  reveal  information  about  the  policies,  procedures, 
or  decisions  of  DoD;  an  example  is  a  computer  model  that 
forecasts  budgetary  outlays.  In  those  instances,  the  requests  must 
be  considered  on  a  case-by-case  basis.  The  record  custodian 
will  invariably  need  the  assistance  of  both  legal  counsel  and  the 
information  specialist  before  making  a  decision  to  release  or 
withhold  this  information  from  the  public. 

Some  information  stored  within  a  computer  has  no  computer 
program  to  retrieve  it'  in  that  case,  the  custodian  is  not  required 
to  develop  a  program  to  fulfill  the  request. 

The  record  custodian  must  also  be  sensitive  to  a  request  for 
electronically  stored  data  that  would  reveal  “company-confidential” 
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infonnation  of  a  contractor  —  especially  to  a  competitor.  That 
sensitivity  is  especially  necessary  wiA  the  reinstatemoit  of  the 
Procurement  Integrity  Act.  In  every  instance  in  which  doubt 
exists,  the  custodian  must  seek  legal  advice  before  releasing  the 
information. 


3.5  MATEaOAL  INSPECTION  AND  RECEIVING 
REPORT  (DD  FORM  250) 

If  the  Department  of  Defense  is  to  benefit  completely  from  the 
full  potential  of  employing  electronic  commerce  in  procurement, 
all  related  activities  must  be  rationalized  into  a  unified  system. 
The  inspection  and  receiving  function  is  an  important  player  in 
the  system. 

The  historic  problems  with  administering  the  DD  Form  250 
should  not  be  minimized.  Its  importance  to  any  successful 
acquisition  is  critical,  and  it  forms  the  basis  of  much  litigatiini. 
The  legal  problems  associated  with  inspection  and  acceptance 
will  not  be  eliminated  by  automating  the  DD  Form  250  fimction. 
However,  the  ability  of  electronic  commerce  to  make  available 
crucial  infonnation  in  real  time  to  the  appropriate  parties  diould 
result  in  eliminating  most  delays  and  misunderstandings  that  tend 
to  spawn  litigation. 

The  inspection  and  receiving  function  does  not  contain  the 
statutory  regimen  that  we  have  in  contract  formation  and  funds 
transfer.  Therefore,  most  restrictions  are  regulatory  and  can 
readily  be  modified,  where  necessary,  to  accommodate  automat¬ 
ing  this  function. 

Historically,  the  signature  plays  an  important  role  in  the 
DD  Form  250  process  since  it  provides  a  hard-copy,  manual 
signature  that  is  very  difficult  to  disavow  at  a  later  ^te  should 
the  authenticating  official  change  his  or  her  mind  about  the  goods 
or  services  being  in  conformity  with  the  contract  requirement. 
In  the  event  of  a  contract  dispute,  electronic  commerce  and  the 
proposed  DD  Form  250  transaction  set  can  provide  completely 
the  kind  of  evidence  of  inspection  that  the  hard-copy  manud 
signature  provides.  The  critical  process  is  to  maintain  a  record 
or  audit  trail  so  that  proof  may  be  recaptured  for  presentation 
in  a  Court  or  Board  of  Contract  Appeals. 

What  is  necessary  is  a  record  of 

•  When  acceptance  occurred 

•  When  goods  were  shipped 

•  When  goods/services  were  received 

•  Whether  the  goods/services  conformed,  and  if  not,  Aether 
the  discrepancies  were  annotated 

•  Traceability. 
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EDI  transaction  sets  can  meet  these  rather  fundamental  require¬ 
ments  with  little  or  no  disagreement.  Further,  real-time  infor¬ 
mation  to  the  appropriate  parties  is  automatic. 

An  EDI-based  system  should  permit  the  Quality  Assurance  Report 
(QAR)  to  “sign-off”  and  distribute  the  information  at  the  same 
time  rather  than  having  the  contractor  distribute  the  information 
after  the  QAR  “sign-off.”  This  should  give  the  Govenunent  a 
better  measure  of  control  as  well  as  speed  distribution,  reduce 
errors,  and  minimize  misimderstandings. 

We  see  no  reason  for  a  manual  hard-copy  signature  for  the 
Material  Inspection  and  Receiving  Report.  Of  course,  the  ap¬ 
propriate  levels  of  security  and  authentication,  as  discuss^ 
above,  should  be  met.  Very  rarely,  if  ever,  should  the  need 
arise  for  encryption  in  automating  this  function. 

3.6  TRADING  PARTNER  AGREEMENTS 

Sometimes  referred  to  as  “preauthorization  agreements,”  TPAs 
should  be  drafted  and  executed  with  substantive  help  from  legal 
counsel.  A  carefully  drafted  TPA  can  be  crucial  in  complying 
with  the  requirement  of  a  writing  in  31  USC§1S01  especially 
when  contracting  for  large  purchases.  Whether  it  is  a  stai^-alone 
agreement  or  simply  a  provision  in  a  master  agreement,  the  TPA 
should  be  executed  before  beginning  trading  with  EDI  transaction 
sets. 

With  respect  to  the  trading  partners,  the  TPA  is  a  key  document 
setting  forth  the  rights  and  obligations  of  the  parties.  It  is 
executed  in  hard  copy  while  tailoring  the  provisions  to  suit  die 
norms  of  the  industry,  whether  transportation,  medical  siqiplies, 
grocery,  etc.  The  following  elements  are  essential  components 
of  any  TPA. 

•  Recital  -  A  statement  that  the  parties  desire  to  enter  a 
mutually  binding  agreement  to  begin  exchanging  EDI  trans¬ 
action  sets.  The  recital  should  state  that  the  parties  intend 
to  be  legally  bound  in  the  same  manner  as  though  they  were 
exchanging  hard-copy  paper  documents. 

•  Standards  -  DoD  has  adopted  the  ANSI  X12  standards 
developed  by  the  ASC  X12.  The  TPA  should  specify  all 
standards  and  their  issuing  organizations;  it  should  include 
data  dictionaries,  segment  dictionaries,  etc.;  and  it  should 
state  how  to  handle  updates  of  newly  adopted  standards. 

•  Documents  -  The  TPA  should  specify  which  transaction  sets 
are  to  be  exchanged  between  &e  parties.  The  TPA  is  a 
good  place  to  incorporate  by  reference  the  industry  guidelines 
that  will  be  followed.  ANSI  ASC  X12  has  developed 
numerous  transaction  sets  in  the  800  series.  Many  DoD 
procurement,  financial,  and  shipping  documents  can  be  trans¬ 
mitted  using  the  general  EDI  transaction,  segments,  and  data 
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element  framework.  Other  times,  the  transaction  sets  will 
necessarily  require  modifications  peculiar  to  DoD. 

•  Duration  ~  The  TPA  should  specify  the  signatory  require¬ 
ments  and  any  necessary  approvals  as  well  as  the  effective 
date  and  period  the  TPA  is  to  be  in  eflect. 

•  Mode  of  EDI  -  DoD  may  require  the  use  of  the  DoD  system, 
or  FTS-2000.  If  approval  is  obtained  to  use  an  independent 
provider,  the  TPA  ^ould  specify  the  name  of  the  provider, 
the  payment  for  services,  and  the  notification  or  procedure 
required  to  change  the  provider. 

•  Acknowledgments /Acceptance  -  The  TPA  should  include  the 
requirement  for  any  special  acknowledgment  or  acceptance 
as  a  condition  to  the  transaction  having  legal  effect.  If  you 
wish  remittance  advice,  for  example,  specify  it  here. 

•  Disputes  -  DoD  contracts  must  contain  the  standard  disputes 
clause  as  specified  in  FAR  52.233.  (Do  not  agree  to  follow 
state  law  or  arbitration  procedure  as  many  trading  partners 
wish  to  do.) 

•  R^erences  -  You  may  incorporate  any  special  publications, 
specifications,  and  guidelines  by  reference,  and  you  should 
specify  the  order  of  priority  in  case  of  internal  conflict. 

•  Security  -  You  should  agree  upon  security  procedures  to  be 
followed  by  each  party  to  protect  business  data  from  im¬ 
proper  access  and/or  disclosure  and  you  should  specify  those 
procedures. 

•  Signatures  -  The  TPA  should  establish  some  method  such 
as  a  discrete  authentication  code  that  can  be  affixed  in  code 
or  symbol  to  each  transaction  set  to  provide  for  authentication 
and  the  confidentiality  of  the  signature  of  the  respective 
parties. 

•  Mailbox  Contents  -  The  TPA  should  specify  when  and  what 
time  the  parties  are  required  to  review  and  collect  the 
contents  of  their  mailboxes.  Other  similar  ordering  or 
shipping  requirements  may  be  further  specified. 

•  Force  Majeure  -  The  TPA  should  include  a  typical  Act  of 
God  clause  excepting  such  things  as  explosion,  or  flood 
from  imposing  liability  on  either  party. 

•  Garbled/Erroneous  Transmissions  -  The  TPA  should  allo¬ 
cate  the  risks  of  garbled  or  erroneous  transmission  as 
negotiated.  It  should  specify  who  shall  be  liable,  if  anyone, 
and  to  what  extent,  for  these  maltransmissions.  If  a  third- 
party  provider  is  responsible,  what  is  the  extent  of  its 
liability? 
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•  Termination  -  If  the  agreement  may  be  terminated  by  either 
party,  the  TPA  should  state  so.  It  should  also  q>ecify  the 
termination  notification  period.  It  should  set  the  parameters 
and  termination  procedures  to  be  followed  if  one  of  the 
parties  falls  below  the  acceptable  standard  of  performance. 

•  Damages  -  The  TPA  should  describe  how  the  parties  should 
handle  special  or  consequential  damages  as  well  as  actual  or 
liquidated  damages. 

•  Whole  Agreement  -  The  TPA  should  contain  the  typical 
whole  agreement  clause  invoking  the  parol  evidence  rule. 

•  Special  Terms  and  Conditions  -  You  may  add  any  other 
special  provisions  that  may  be  wise  and  necessary  to  the 
efficient  trading  operation. 

The  Electronic  Messaging  Services  Task  Force,  a  Subcommittee 
on  Electronic  Commercial  Practices,  Uniform  Commercial  Code 
Committee,  Section  of  Business  Law,  American  Bar  Association 
has  prepared  a  draft  model  agreement  to  assist  the  practiticmer 
in  preparing  TPAs.  It  should  be  used  only  as  an  aid  in 
conjimction  with  advice  from  your  agency  legal  counsel. 

3.7  TfflRD-PARTY  SERVICE  PROVIDER 
AGREEMENTS 

The  DoD  policy  requires  that  its  agencies  use  the  Defense 
Switched  Network  (DSN)  or  the  Defense  Data  Network  (DDN) 
or  FTS  2(X)0  as  the  transmission  system  of  first  choice  for  aU 
new  acquisition  requirements.  The  commercial  sector,  however, 
offers  transmission  services  with  a  host  of  value-added  services. 

If  you  decide  to  use  a  commercial  third-party  or  VAN,  you  have 
many  choices  and  the  market  is  growing  more  competitive. 
Third-party  providers  can  be  of  great  service  in  getting  any  EDI 
program  off  to  a  good,  sound,  solid  start.  They  can  provide  a 
variety  of  services  especially  in  getting  many  small  unsophisti¬ 
cated  trading  partners  conversant  with  the  technology,  can  assist 
in  selecting  hardware,  and  software  and  in  providing  training. 

Usually  the  third-party  service  providers  have  their  own  printed 
contract  forms;  however,  since  competition  is  growing  among 
these  companies,  you  should  have  a  good  deal  of  leverage  in 
negotiating  acceptable  terms  and  conditions. 

As  with  any  legal  agreement,  the  third-party  service  provider 
agreement  ^ould  not  be  drafted  and  executed  without  t^  assis¬ 
tance  of  competent  legal  advice.  Many  of  the  terms  and  condi¬ 
tions  discussed  above  under  TPAs  will  be  used  in  the  third-party 
agreement.  For  example,  the  merger  or  whole  agreement  clause 
is  a  necessity  as  well  as  the  force  nujeure  clause,  which 
exonerates  the  provider  from  liability  connected  with  acts  of  God, 
such  as  fire,  flood  and  a  variety  of  causes  outside  the  control 
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of  the  service  provider.  In  addition,  you  should  negotiate 

acceptable  terms  on  the  following: 

•  A  complete  description  of  the  services  to  be  provided  to  the 
respective  trading  partners. 

•  The  language  specifying  that  the  third-party  provider  has  no 
independent  property  interest  in  the  data  and  further, 
foreclosing  any  claim  that  the  provider  has  added  value  to 
the  data  giving  some  legal  right  to  a  mechanics  lien  or  a 
possessory  lien. 

•  An  understanding  that  the  provider  will  store  records  or 
perform  some  archival  service  should  be  covered  along  with 
the  associated  cost.  If  you  desire  back-rip  copies,  this 
agreement  should  provide  for  them.  It  should  also  provide 
for  how  long  back-up  copies  will  be  kept. 

•  The  confidentiality,  integrity,  and  security  measures  to  be 
provided  need  to  be  memorialized  in  the  agreement.  For 
example,  “will  the  signature  authentication  code  be 
encrypted?” 

•  The  third-party  provider’s  responsibility  for  accurate,  reliable 
service.  You  should  also  designate  the  third-party’s 
liability.  What  is  the  measure  of  the  provider’s  liability? 
Will  it  be  responsible  for  compensatory  damages  in  case  of 
data  loss,  delay,  mistakes,  or  misdirection?  How  about 
liquidated  damages?  It  is  not  customary  to  expect  exemplary 
or  punitive  damages;  nevertheless,  this  should  be  spelled  out 
in  the  agreement. 

•  When  the  agreement  will  terminate,  whether  it  can  be 
changed  periodically,  and  udiether  the  parties  are  free  to 
change  service  providers  after  one  has  been  agreed  upon. 
This  is  the  time  and  place  to  so  specify.  Agree  upon  a 
standard  of  service  below  which  the  parties  may  terminate 
the  agreement  without  risk  of  breach  and  associated  damages. 

•  Very  definite  language  detailing  exactly  how  network  charges, 
if  any,  are  to  be  shared  between  the  suppliers  and  die 
customers.  Perhaps  DoD  may  be  able  to  negotiate  a  no-cost 
service  provider  agreement  with  the  network.  There  are 
instances  today  where  this  is  so,  even  though  EDI  has  not 
burgeoned  yet,  and  it  will  get  even  more  competitive. 

•  A  warranty  that  the  provider’s  system,  when  used  in  con¬ 
sonance  with  procedures  specified,  will  perform  as  stated. 
This  should  not  mean  the  provider  has  absolute  liability  but 
that  the  provider  should  deliver  services  as  promised  barring 
extraordinary  circumstances.  Inclusion  of  provisirm  that  this 
warranty  is  in  lieu  of  any  warranties  implied  by  law  is  a 
reasonable  requirement. 
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•  The  network  requirements  to  support  ANSI  or  Electronic 
Data  Interchange  for  Administration,  Commerce,  and 
Transport  (EDIFACT)  standards.  Your  expectations  should 
be  specified.  What  audit  trails  are  expected? 

•  All  record  keeping  requirements.  You  should  specify  all 
such  requirements.  For  example,  when  can  the  provider 
discard  the  data?  If  the  provider  wishes  a  short  statute  of 
limitations  beyond  which  its  liability  is  forgiven,  that  nuy 
be  beyond  a  Government  negotiator’s  power  to  agree  to;  use 
the  statutory  period  provided  by  Federal  law. 


j 
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4.0  SYSTEM  ARCHITECTURE  AND 
ENVIRONMENT 


This  chapter  describes  the  system  architecture  that  DoD  uses  for 
electronic  commerce  (EC).  The  chapter  begins  with  a  description 
of  the  DoD  Standard  System  architecture,  including  the  intelligent 
gateway,  Computer-Aided  Acquisition  and  Logistic  Support 
(CALS),  integration,  trusted  systems/computer  security  integra¬ 
tion,  an  integrated  network  strategy,  the  EDI  VAN  integratimi, 
and  the  procurement  bulletin  board  integrations.  It  then  presents 
a  brief  description  of  the  system  architectures  used  in  private 
industry,  a  discussion  of  application  integration,  and  the  generic 
functions  performed  by  translation  software. 

4.1  SYCTEM  ARCHITECTURE  OF  THE  DoD 
STANDARD  SYSTEM 

The  system  architecture  of  a  DoD  EC/EDI  implementation  involves 
complex  systems  integration  of  a  number  of  crucial  components. 
The  end  result  is  horizontal  integration  of  applications  within  DoD, 
a  single  face  to  private  industry,  and  greatly  enhanced  efficiency 
and  effectiveness  of  DoD  applications.  Figure  4. 1-1  shows  some  of 
the  components  in  the  engineering  approach  that  need  to  be 
integrated  into  the  DoD  standard  system. 


Data  Communications: 
DDN,  FTS2000, 
AUTODIN,  etc. 


Distributed  Networking: 
PCs,  Minis,  Mainframes 
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Value  Added  Services: 
Translators,  'gatewajrs,'' 
Electronic  Mail,  etc. 


DoD  Standard 
Electronic  Commerce 
Systems  Approach 


Computer  Security: 
Public  Key  Encryption, 
DES,  LRAM,  eSM,  etc. 


Information  Modeling; 
Data  flows.  Simulation, 
Queuing,  Backup,  etc. 


Standards: 

ANSI  X12  (EDI),  X.400 
(EM),  1840A  (CALS), ... 


Figure  4.1-1  Engineering  Approach:  Complex  Systems  Integration 


4.1.1  Overview 

The  underlying  architecture  for  the  DoD  standard  system  calls 
for  the  integration  of  all  existing  Service  and  agency  systems 
through  the  use  of  a  series  of  Intelligent  Gateway  Processors 
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(IGPs)  that  will  serve  either  as  external  minicomputers  or  as 
resident  software  on  one  of  the  existing  computer  systems.  The 
combination  of  IGPs  and  existing  computer  systems  will  hasten 
the  use  of  EC/EDI  techniques  without  the  replacing  or  reprogram¬ 
ming  existing  computer  systems  and  will  make  the  following 
benefits  available: 

•  Trusted  systems  integration  into  electronic  mail  and  data  base 
transfers 

•  CALS  integration 

•  Computer  bulletin  board  integration,  especially  for  such 
activities  as  procurements 

•  The  creation  of  a  virtual  system  of  systems,  with  everything 
connected  to  everything. 

The  following  illustrations  show  the  difference  between  the  “stan¬ 
dard"  EDI  approach,  and  the  DoD  standard  EC  through  EDI 
approach.  In  Figure  4. 1.1-1,  note  the  bold  box  around  the  EDI 
translator:  in  most  systems  this  is  the  beginning  and  the  end  of 
an  integrated  approach,  leaving  it  to  the  individual  user  to  deal 
with  networks,  telecommunications,  and  applications  interfaces. 
Figure  4. 1.1-2  shows  the  role  that  the  EC  systems  approach  can 
play,  integrating  end-to-end. 


Figure  4. 1.1-1  Electronic  Data  Interchange:  Only  Part  of  the  Story 
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Figure  4. 1.1-2  Electronic  Commerce  via  the  IGP: 
The  Rest  of  the  Story 


4.1.2  The  Lawrence  Livermore  National  Laboratory 
Intelligent  Gateway 

One  of  the  key  components  in  the  EC  systems  approach  is  die 
LLNL  intelligent  gateway  processor.  The  IGP  is  a  combination 
of  hardware  and  software  designed  for  transparent,  “intelligent” 
connectivity  to  heterogeneous  computers.  Originally  designed  at 
LLNL  almost  a  decade  ago,  it  was  based  on  pioneering  work 
done  at  die  National  Bureau  of  Standards  [now  the  National 
Institute  of  Standards  and  Technology  (NIST)].  The  original 
design  has  undergone  many  revisions  and  inqirovements  over  the 
years,  and  the  basic  requirements  are  currently  as  follows: 

•  Hardware  -  Any  standard  UNIX  platform,  including  bodi 
AT&T  UNIX  and  OSF  UNIX.  This  hardware  includes  even 
80386-  based  personal  computers  (PCs)  running  UNIX. 

The  initial  recommendation  for  a  pilot  platform  is  the  AT&T 
3B2/600G.  That  computer  was  chosen  because  of  its  robust¬ 
ness,  inexpensive  price,  and  ready  availability  on  Govern¬ 
ment  contract. 

•  Software  -  The  IGP  software,  originally  developed  at  LLNL 
and  currently  in  use  by  over  20,000  DoD  users  worldwide. 

In  a  technology-transfer  agreement,  the  IGP  software  has 
been  licensed  to  Control  Data  Corporation  (CDC),  and  both 
software  and  services  are  available  under  the  ASCENT 
product  line.  The  agreement  ensures  that  the  operational 
implementation  of  the  IGP  is  commercially  siqpported  and 
maintained. 
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The  following  three  illustrations  show  the  state  of  affairs  without 
the  IGP,  the  result  of  adding  a  traditional  gateway,  and  finally 
the  functionality  provided  by  the  full  functional  integration  that 
the  IGP  offers. 

Figure  4. 1.2-1  shows  there  are  still  organizaticms  that  require  a 
separate  terminal  for  access  to  each  different  type  of  mainframe 
computer. 


Figure  4. 1.2*1  Without  the  IGP:  Computers,  Multiple  Terminals 


The  situation  shown  in  Figure  4. 1.2-2  is  the  result  of  employing 
what  is  today  described  as  gateway  technology.  However,  almost 
all  gateways  available  only  bring  one  to  the  doorway  of  another 
computer  system,  leaving  the  user  to  deal  with  that  computer’s 
applications  programs.  In  addition,  most  current  “gateways”  rely 
on  a  limited  range  of  connectivity  options  (usually  Ethernet). 

The  value  added  by  the  intelligent  gateway  processor  is  that  it 
mediates  more  than  the  physical  connection  between  machines: 
it  goes  into  the  other  systems  and  extracts  the  needed  data  for 
the  user  without  the  user’s  needing  to  know  how  to  use  that 
computer  or  that  computer’s  application  programs.  In  addition, 
the  IGP  is  designed  to  transparently  link  various  types  of 
telecommunications  options  with  a  single  machine.  Figure  4. 1.2-3 
shows  how  this  will  appear. 
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Hewlett-Packard 


VTCP-IP 


^  DoD  Standard 
Dectronk  Commerce 
^Systems  Approach^ 


Serial  ISDN, 
19,2e0li|a 


Figure  4. 1.2-2  With  A  Gateway:  A  Single  Access  Point  to 
Multiple  Resources 
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Figure  4. 1.2-3  With  the  IGP:  A  Single  Access  Point  to  Data  of  All  Types 


4.1.3  CALS  Integration 

For  years  CALS  has  been  a  joint  DoD-industry  program  to 
provide  standardized  ways  of  exchanging  engineering  drawings 
and  technical  data.  Until  recently,  however,  the  telecommunica¬ 
tions  aspects  had  not  been  dealt  with  in  the  CALS  program. 
Fortunately,  DoD  recently  saw  the  synergy  between  the  EC/EDI 
initiative  and  CALS,  and  has  determined  that  the  two  programs 
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are  complementary,  pursuing  common  technical  solutions  for 
interchanging  CALS  and  EC/EDI  information.  DoD  has  publicly 
stated  that  it  is  committed  to  the  use  of  EDI  transactions  in 
CALS,  and  vice-versa  whenever  appropriate.  As  a  part  of  that 
commitment,  CALS  work  and  EC/EDI  work  are  now  coordinated 
in  the  same  organization  in  the  Office  of  the  Secretary  of 
Defense.  In  additicm,  DoD  is  committed  to  working  with  the 
CALS  Industry  Steering  Groi^  on  further  integration  strategies. 

Figure  4. 1.3-1  shows  the  range  of  activities  wdiich  will  be 
included  in  a  strategy  integrating  both  CALS  and  EC/EDI 
techniques. 


Figure  4. 1.3-2  shows  some  of  the  fimctional  areas  in  which 
CALS  applications  can  take  advantage  of  EC/EDI  techniques. 

4.1.4  Trusted  Systems/Computer  Security  Integration 

Anodier  crucial  part  of  die  DoD  inqilementation  plan  is  the  inchisiaa 
of  “trusted  ^sterns”  technology  in  die  eotiie  design,  from  die 
qierating  systems  to  die  individual  messages  passed.  Trusted  systems 
are  sometimes  called  protected  or  aicrypted  systems,  and  dieir  basic 
distinguishing  factor  is  diat  they  provide  die  capability  of  knowing 
for  certain  that  a  message  received  was  in  fiKt  sent  by  die  person  or 
organization  who  purports  to  have  sent  it  and  duu  message  has  not 
been  changed  by  a  diird  party.  In  addition,  trusted  systems  enable 
the  sender  to  provide  die  capability  of  encrypting  a  message  or 
transaction  so  that  it  cannot  be  read  by  anyone  but  die  intended 
recipient. 
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Figure  4. 1.3-2  EC/CALS  Functional  Integration  Target 


4. 1.4.1  Trusted  Operating  Systems 

With  the  threat  and  reality  of  “cracker/hacker”  computer  break- 
ins,  it  is  increasingly  important  to  be  able  to  deal  with  potential 
outsiders  attempting  to  enter  a  computer  system.  For  diis  reason 
trusted  operating  systems  are  being  designed  and  tested.  The 
EC/EDI  system  described  here  udll  review  the  results  of  ti»«riiig 
by  the  NIST  and  the  National  Security  Agency  to  determine  the 
best  operating  systems  to  be  utilized  for  the  iiiq>lemeiitation  of 
the  EC/EDI  program.  Initial  indications  are  that  leaning  con¬ 
tenders  in  this  area  are  AT&T  multilevel  secure  (MLS)  UNIX 
and  Trusted  Information  Systems  (TIS)  Trusted  XENK/MACH. 
In  any  case,  the  DoD  EC/EDI  Standard  System  will  conq>ly  fully 
with  any  standards  issued  by  NIST. 

4. 1.4.2  Protection  of  Message  and  Transaction  Traffic 

A  combination  of  computer  security  techniques  will  be  to 
protect  message  and  transaction  traffic.  That  combination  will 
include  the  best  of  the  DES  with  Public  Key  Cryptography  (PKC) 
to  provide  the  capability  to  do  the  following: 

•  Electronically  sign  any  type  of  digiul  file  or  document 

•  Electronically  seal  (fully  encrypt)  a  digiul  file  or  document, 
or  any  portion  of  that  file  or  document 

•  Provide  electronic  protection  of  vendor  proprietary  daU 
[e.g.,  bids  responding  to  an  request  for  quoUtions  (RFQ)  or 
request  for  proposals  (RFP),  etc.] 


911031 


4.0.7 


•  Provide  appropriate  levels  of  end-to-end  data  protection  and 
privacy  for  all  types  of  DoD  logistics-  and  business-related 
transactions  and  documents. 

In  addition,  the  implementation  either  utilizes  strictly  commercial 
off-the-shelf  components,  or  will  work  to  commercialize  any 
appropriate  component,  so  that  private  industry  can  take  advantage 
of  and  be  compatible  with  the  DoD  Standard  System. 

The  following  standard  systems  and  commercial  products  are 
among  those  being  considered  for  inclusion: 

•  LLNL  trusted  mail  (TM) 

•  DARPA/nS  privacy  enhanced  mail  (PEM) 

•  RSA  toolkit  for  internet  PEM  (TIPEM) 

•  NIST  data  encryption  standard  (DES) 

•  Internet  Activities  Board  (lAB) 

•  Bell  Northern  Research  (BNR)  packet  data  security  overlay 
(PDSO) 

•  Livermore  risk  assessment  methodology  (LRAM) 

•  Livermore  computer  security  monitor  (CSM) 

•  Plus  the  security  aspects  of  X12,  X.4(X),  and  other  standards. 

4.1.5  Integrated  Network  Strategy 

The  EC/EDI  approach  to  networks  is  to  provide  an  integration 
of  three  overall  systems:  the  Electronic  Commerce  Test  Network 
(ECTN),  the  EC  Operational  Pilot  Network  (OPN),  and  finally 
Ae  EC  Operational  Network  (ECON). 

The  ECTN  primarily  serves  as  a  testbed  for  developing  new 
capabilities  and  for  testing  new  integration  strategies.  Its  specific 
purposes  are  the  following: 

•  Establish  network  interoperability  with  commercial  VANs, 
linking  them  with  DoD  systems 

•  Establish  network  interoperability  with  the  entire  range  of 
potential  DoD  systems,  regardless  of  the  network  host  on 
which  they  reside 

•  Design  and  test  complex  integrated  software  for  enhancing 
connectivity  to  the  wide  range  of  heterogeneous  computers 
and  applications  described  above 

•  Test  and  evaluate  both  software-based  and  hardware-based 
data  protection  and  security  systems 
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Test  and  evaluate  commercial  EDI  translation  and  nupping 
software. 


The  EC  Operational  Pilot  Network  is  to  serve  as  a  release  point 
for  tested  solutions  for  use  in  an  operational  environment.  OPN 
users  are  doing  real  work  with  the  technology  that  has  been 
tested  in  the  EC  test  network.  As  solutions  are  tested  and 
validated  in  the  ECTN,  they  are  migrated  in  an  orderly  ftishion 
into  the  OPN.  An  example  of  this  is  the  logistics  information 
network  (LINK)  porticm  of  the  EC/EDI  project,  vdiich  provided 
connectivity  between  logistics  data  bases  around  the  world  and 
the  troops  in  the  field  in  Operation  Desert  Storm.  In  addition, 
the  OPN  will  provide  real-world  identificaticm  of  needs  that  the 
commercial  sector  has  yet  to  meet,  which  will  in  turn  feed  back 
into  the  ECTN  for  appropriate  development. 

The  EC  Operational  Network  is  the  umbrella  under  vidiich  all 
activities  work.  Just  as  solutions  are  validated  in  the  ECTN  and 
migrated  to  the  OPN,  the  same  process  applies  to  the  ECON. 
As  solutions  are  validated  in  the  OPN,  diey  will  be  endorsed  for 
DoD-wide  use  in  the  ECON. 

A  crucial  point  in  viewing  this  process  is  that  the  entire  system 
is  designed  to  do  useful  work  for  someone  from  the  very 
beginning.  The  DoD  approach  is  not  to  engineer  a  proof  of 
principle,  but  rather  to  ^  real  work  and  to  satisfy  re^  needs. 
The  EC/EDI  system  is  a  transitional  system,  not  a  turnkey 
system.  It  answered  real  needs  in  the  Operation  Desert 
SMeld/Desert  Storm  arena,  and  wiU  continue  to  answer  real  needs 
in  relief  efforts  in  other  arenas  in  the  days  to  come. 

Figure  4. 1.5-1  sho>V5  a  graphic  view  of  the  interrelationship  of 
the  three  networks. 


Figure  4. 1.5-1  Electronic  Commerce  Network  Overview 
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Figure  4.1.S-2  shows  some  of  the  functicmal  areas  in  which 
support  has  already  been  demonstrated  for  the  early  implemen¬ 
tation  of  the  EC/EDI  standard  systems  approach  and  (mce  again 
shows  the  relationship  of  the  ECTN  and  OPN  to  the  ECON. 


Figure  4.1.S-2  Relationship  of  ECTN  and  OPN  to  ECON 


4.1.6  EDI  VAN  Integration 

The  DoD  currently  does  business  with  hundreds  of 
thousands  of  companies,  large  and  small,  many  of  whom 
are  already  using  EDI  techniques.  However,  the  VANs 
those  businesses  are  using  comprise  the  complete  range 
of  VANs  available.  In  order  for  DoD  to  most  efficiently 
utilize  the  capabilities  of  the  industry,  it  needs  to  adapt 
the  techniques  used  by  private  industry,  which  are  tradi¬ 
tionally  very  vertically  integrated,  into  a  DoD-wide 
horizontal  integration  strategy.  This  will  permit  any  DoD 
user  to  deal  with  any  private  industry  user,  regardless  of 
the  VAN  used  by  that  private-industry  user.  An  illustra¬ 
tion  of  how  this  might  work  appears  below,  following  a 
description  of  the  procurement  bulletin  board  integration 
strategy. 

4.1.7  Procurement  Bulletin  Board  Integration 

One  of  the  more  costly  aspects  of  procurement  in  DoD 
and  in  fact  throughout  the  Federal  Government  is  small 
procurement.  The  administrative  cost  of  making  a  single 
purchase  of  an  item  under  $25,000  can  be  anywhere  from 
$50  to  $250  or  more.  EC/EDI  techniques,  utilizing  a 
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computer  bulletin  board  look  and  feel,  have  the  potential  to  solve 
that  problem  and  still  meet  the  following  requiremmits: 


•  Timely  posting  of  new  RFQs 

•  Even  competition,  in  accordance  with  FAR  13.105 

•  Lower  cost  than  current  paper-based  and  telephone-based 
systems 

•  Maintenance  of  integrity  and  ctmlidentiality  of  bids  sub¬ 
mitted 

•  Provision  of  award  information  in  a  trusted  fuhion  to  all 
bidders,  as  aiq>rc^riate 

•  Integration  with  major  information  systems  already  in  place, 
such  as  the  Base  Contracting  Automated  System  (BCAS), 
used  throughout  the  Air  Force,  Marine  Corps,  Navy,  and 
some  Army  bases 

•  Integration  with  standard  X12  EDI  transactions 

•  Integration  with  two-way  electronic  mail  between  su{^liers 
and  DoD. 

The  EC/EDI  integration  plan  includes  electronic  mail  as  the 

carrier  of  information,  utilizing  trusted  system  techniques  to 

ensure  confidentiality  of  bids.  The  series  of  events  would  follow 

a  sequence  similar  to  the  following: 

•  DoD  contracting  and  procurement  offices  provide  RFQs  by 
electronic  mail  to  a  DoD  computer  host. 

•  The  DoD  computer  host,  utilizing  intelligent  gateway  tech¬ 
niques,  disseminates  that  informatitm  to  all  participating 
commercial  VANs,  utilizing  whatever  telecommunication 
channels  and  techniques  are  necessary. 

•  The  VANs,  on  receipt  of  the  information,  make  it  available 
to  their  private-industry  suppliers/subscribers  for  standard 
fees. 

•  Private-industry  subscribers  utilize  the  postings  on  die  VANs 
in  whatever  method  the  VAN  provides  as  long  as  they  are 
able  to  make  a  bid  or  other  response  through  electronic  mail. 

•  The  VANs  receive  electronic  mail  bids  and  responses  from 
private-industry  subscribers  and  forward  them  direcdy  to  the 
DoD  host. 
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•  The  DoD  host  computer  receives  a  bid  or  other  response 
from  the  VAN  connection;  that  communication  is  time- 
stamped  and  archived  for  audit-trail  purposes,  and  is  simul¬ 
taneously  forwarded  to  the  original  contracting  officer. 

•  After  the  appropriate  period  has  passed,  a  contract  award  is 
made,  and  that  information  is  sent  out  via  the  same  channels 
to  die  awardee  and  posted  on  die  bulletin  board  of  each  VAN 
as  a  contract  awarded. 

•  At  this  point,  the  EDI  transactions  that  were  a  part  of  this 
entire  process  interface  with  the  rest  of  the  purchasing 
process,  finally  culminating  in  the  payment  of  an  invoice 
(which  was  also  received  electronically). 

A  number  of  unique  features  in  this  system  should  be  pointed 

out,  most  of  which  would  be  impossible  with  a  single,  third-party 

VAN.  Among  them: 

•  As  appropriate,  trusted  mail  components  will  be  utilized  at 
both  ends  of  the  spectrum,  i.e.,  the  individual  supplier  and 
the  DoD  contracting  officer. 

•  Private-industry  suppliers  may  choose  the  VAN  that  provides 
the  best  price/performance  combination,  thus  encouraging 
competition  among  the  VANs.  In  addition,  suppliers  in 
private  industry  already  using  one  VAN  will  not  be  required 
to  switch,  thus  avoiding  the  expense  of  changeover. 

•  The  DoD  host  computer  will  have  full  audit-trail  capabilities, 
with  archiving  being  done  to  optical  disk  media  [such  as 
write-once,  read-many  (WORM)  drives]. 

•  The  DoD  contracting  officers  and  others  involved  in  the 
procurement  cycle  will  have  complete  control  over  dieir  data 
and  the  uses  to  which  those  data  are  put,  without  being 
hostage  to  a  third-party  contractor. 

•  The  requirement  that  private  industry  approach  DoD  through 
commercial  VANs  avoids  the  necessity  of  having  DoD  main¬ 
tain  vendor  accounts  on  Government  computers. 

•  Basing  the  system  on  electronic  mail  and  query  by  mail 
techniques  avoids  the  requirement  for  having  thousands  of 
simultaneous  log-ins  on  any  individual  computer,  either 
DoD’s  or  a  commercial  VAN’s. 

•  The  hosting  of  information  on  a  DoD  computer  allows  for 
powerful  statistical  analysis  of  data,  including  cross-VAN 
comparisons  of  VAN  performance. 
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•  The  hosting  of  information  on  a  DoD  computer  inqiroves  the 
preparation  phase,  including  the  automatic  scanning  of 
debarred  lists,  local  “tweaking”  to  provide  for  minority  or 
local  suppliers,  etc. 

Figure  4. 1.7-1  shows  the  DoD  strategy  for  integration  of  the 
commercial  VANs  with  the  DoD  ECON,  to  provide  Government 
buyers  and  commercial  suppliers  with  broad-based  connectivity. 


Figure  4.1.7-1  Procurement  Network  Strategy 


4.2  SYSTEM  ARCHITECTURES  USED  IN 
PRIVATE  INDUSTRY 

Private  industry’s  approach  to  the  implementation  of  EDI  has 
almost  always  been  based  on  a  large  buyer  dictating  capabilities 
and  requirements  to  smaller  suppliers. 

That  aj^roach  works  Ene  in  a  one-to-one  situaticm,  but  even  then 
it  has  problems.  For  example,  if  your  machine  shop  sells  parts 
to  both  Companies  A  and  B,  you  will  likely  have  to  have  two 
completely  separate  means  of  getting  data  from  your  system  into 
theirs.  Common  industry  approaches  are: 

•  Microcomputer-to-trading-partner  ’s-mainframe  method 
This  method  utilizes  either  translation  software  or 
data  input  screens  at  the  microcomputer  level.  Once 
data  have  been  entered  or  translated,  the  trading 
partner’s  mainframe  computer  is  contacted  by 
telephone,  and  the  data  are  transferred.  Data  waiting 
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for  the  microcomputer-based  company  are  usually  transferred 
to  the  microcomputer  at  that  time. 

•  MainJr<me~to-m<unJrame  approach 

This  method  utilizes  translation  software  at  the  mainfnme 
level  although  applications  software  may  have  been  modified 
to  produce  X12  standard  format  directly.  Once  a  sufficient 
amount  of  data  is  accumulated  at  one  maintinme  computer, 
that  computer  communicates  with  the  other  by  telephone. 
Otherwise,  this  method  is  similar  to  the  previous  method. 

•  Microcomputer  or  mainframe  via  electronic  mail  network  to 
trading  partner’s  mainframe  method 

This  method  is  similar  to  the  two  previous  methods,  with 
the  exception  that  an  electronic  mail  network  serves  as  a  link 
between  the  two  trading  partners.  In  addition,  that  network 
may  also  perform  translation  functions.  One  major  advantage 
of  a  system  based  on  electronic  mail  is  that  a  single  netwoik 
may  have  access  to  many  different  trading  partners.  In  fact, 
an  entire  industry  group  of  EDI  VANs  specialize  in  electronic 
mail  for  EDI  purposes. 

4.3  APPLICATION  INTEGRATION 

Application  integration  is  where  the  real  value  of  EC  through 
EDI  becomes  most  evident.  An  organization  that  feels  that  it  can 
benefit  from  this  technology  without  becoming  committed  to 
implementing  it  fiiUy  will  lose  money  and  time  in  the  long  run. 
Initial  steps  along  the  way  will  in  fact  be  “paving  the  cow  paths” 
of  the  past,  but  the  intent  of  the  DoD  from  the  beginning  is  to 
go  all  paperless  as  soon  as  possible!  Half  steps  won’t  get  you 
there. 

Given  that  this  is  the  direction  in  which  DoD  plans  to  go,  what 
steps  should  you  take  now?  First,  look  at  your  systems  with 
fresh  eyes.  Forget  the  bottlenecks  that  exist  and  play  “What  iP 
with  the  power  of  the  computer  and  the  network.  It  is  not  at  all 
unreasonable  to  come  up  with  a  system  which  does  away  almost 
completely  with  such  things  as  invoices,  duplicate  copies  of  any 
piece  of  correspondence  (including  electronic,  of  course),  multi¬ 
ple  contract  files,  and  so  on.  However,  the  path  from  here  to 
there  is  not  the  automation  of  the  paper,  nor  the  paving  of  the 
cow  path.  It  is  your  intelligent  examination  of  your  current 
applications,  finding  the  functionality  in  them  udiich  can  be 
enlunced  by  electronic  interchange  both  to  and  from.  You  will 
probably  find  procedures  for  which  there  is  no  need  udiatsoever. 
Fine,  get  rid  of  them.  More  importantly,  you  will  discover  that 
you  now  have  capabilities  that  in  the  past  you  could  only  wish 
for,  if  you  just  make  a  few  changes  at  your  end. 

4.4  TRANSLATION 

Translation  is  the  automated  process  of  translating  the  proprietary 
data  into  ASC  X12  standard  for  sending  data  and  reversing  that 
process  for  receiving  data.  The  translation  program  uses  “table 
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drivea”  subroutines  to  generalize  processing  regardless  of  the 
actual  application  being  processed.  Specific  action  is  taken  by 
the  program  depending  on  the  data  being  processed  and  the 
particular  tables  associated  with  the  transaction  set. 

The  ASC  X12  standard  defines  the  results  of  the  processing,  not 
how  a  program  is  designed  nor  how  it  operates.  As  a  conse¬ 
quence,  commercial  software  packages  provide  “core  translation” 
and  other  related  functions  designed  to  support  different  EDI 
environments.  Their  costs  range  from  a  few  hundred  dollars  to 
$200,000.  The  translation  software  decision  to  “make  or  buy” 
must  consider  many  factors;  however,  the  availability  of  a 
relatively  inexpensive,  proven  commercial  software  packages 
supported  by  a  growing  industry  should  make  development  un¬ 
necessary.  EDI  software  should  be  managed  as  “system 
software”  versus  “application  software.” 
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5.0  MAB^NANCE 


This  chapter  describes  the  procedures  for  maintaining  the  DoD 
guidelines  and  conventions.  It  aira  presents  a  section  on  ver¬ 
sion/release  timing. 

5.1  MAINTAINING  GUIDELINES 

The  DLA,  as  DoD’s  Executive  Agent  for  EDI  and  PLUS,  has 
established  a  joint  program  office  to  oversee  implementation  of 
EDI.  Some  of  the  functions  of  this  program  office  are  to 
maintain  configuration  control  of  related  standards  and  common 
support  packages  (e.g.,  versions  of  ASC  X12  standards  and 
PLUS  algorithms  employed),  participate  in  the  standards-setting 
process,  and  ensure  compliance  with  approved  EDI  standards. 

To  accomplish  these  fimctions,  the  joint  program  office  has 
established  a  conventions  and  standards  development  and  main¬ 
tenance  process  whose  objectives  are:  (1)  to  obtain  ASC  X12 
data  requirements  from  the  DoD  Components  and  present  the 
requirements  to  the  ASC  X12  for  consideration  as  ANSI  stan¬ 
dards,  and  (2)  to  develop  and  maintain  conventions  for  use  by 
DoD  Components  and  their  potential  trading  partners. 

To  take  advantage  of,  and  not  duplicate,  existing  data  stan¬ 
dardization  processes,  the  EA  has  established  focal  points 
within  the  ASD  Offices,  the  Military  Services,  and  the 
Defense  Agencies  from  which  EDI  information  is  obtained 
and  disseminated. 

5.1.1  Deve!opment  and  Maintenance  of  DoD  Conventions 

The  EA’s  primary  source  of  information  about  DoD’s  data 
requirements  is  the  EDI  Users  Group.  That  group  is  chaired  by 
a  representative  of  the  ASD(P&L)  and  consists  of  representatives 
from  OSD  offices.  Military  Services,  and  Defense  Agencies.  It 
recommends  the  establishment  of  working  groups  to  facilitate 
consensus  among  the  DoD  Components  with  regard  to  DoD 
conventions  and  DoD’s  voting  position  at  ASC  X12  meetings. 
The  EDI  Users  Group  also  provides  support  for  EDI  education 
and  training. 

Changes  to  this  publication  and  recommended  changes  to  ANSI 
ASC  X12  should  be  forwarded  through  your  organizational  point 
of  contact  for  data  standardization  to: 

EDI  Standards  Coordinator 
ATTN:  DLA-ZIE 
Cameron  Station 
Alexandria,  VA  22304-6100 


See  Chapter  9.0  for  reproducible  forms. 


5.1.2  The  Defense  Logistics  Standard  Systems  (DLSS) 
and  Defense  Transportation  EDI 

Since  1962,  the  Defense  Logistics  Standard  Systems  (DLSS)  have 
provided  procedures  for  communicating  requirements,  moving 
materiel,  and  performing  other  inter-Service  tasks  needed  to 
support  the  continuing  operation  of  DoD’s  logistics  systems. 

Meeting  the  challenges  of  the  next  decade  will  require  a  new 
approach,  new  standards,  and  new  technology. 

In  1984,  a  program  called  Modernization  of  Defense  Logistics 
Standard  Systems  (MODELS)  was  initiated  to  meet  this  challenge 
through  the  efforts  of  its  inter-Service/ Agency  Functional  Work¬ 
ing  Group.  The  MODELS  program  has  developed  new  EDI 
logistics  transactions  conforming  to  ASC  X12  EDI  standards. 
MODELS  has  also  conducted  live  tests  and  simulations  to  explore 
various  methods  of  evolving  from  the  current  flxed-length  DLSS 
transaction  to  the  more  flexible  variable-length  ASC  X12  trans¬ 
action  sets. 

To  capitalize  on  EDI  advances  in  commercial  transportation,  the 
Defense  Transportation  EDI  (DTEDl)  project  was  initiated.  The 
DTEDI  Committee  worked  closely  with  industry,  carriers,  and 
business  standards  groups  to  develop  an  ASC  X12  transaction 
set  acceptable  to  both  DoD  and  industry.  The  success  of  this 
project  demonstrated  the  feasibility  of  adopting  ASC  X12  stan¬ 
dards  for  internal  as  well  as  external  DoD  use. 

The  positive  results  of  these  efforts  provide  the  basis  for  evolu¬ 
tion  of  DLSS  to  a  modernized  system  incorporating  the  full 
functionality  of  the  existing  DLSS  and  the  enhanced  capabilities 
and  technical  improvements  resulting  from  MODELS  and 
DTEDI. 

This  future  system  is  called  the  Defense  Logistics  Management 
System  (DLMS).  Through  the  use  of  ASC  X12  standards  and 
supporting  technology  base,  DLMS  will  provide  maximum 
flexibility  in  supporting  DoD’s  internal  and  external  logistics 
information  needs. 

The  DoD  Executive  Agent  for  EC/EDI/PLUS  is  working  closely 
with  the  Defense  Logistics  Standard  System  Division  to  ensure 
a  coordinated  DoD  position  with  respect  to  the  ASC  X12 
standards  development  and  maintenance  process.  Military  Ser¬ 
vices  and  Agencies  should  continue  to  utilize  existing  procedures 
for  administration  of  DLSS. 


5.2  MAINTAINING  X12  STANDARDS 

Chapter  9.0,  Section  9.1  provides  an  explanation  of  the  ANSI 
ASC  XI2  organization,  standards  process,  standards  background, 
and  forms  extracted  from  the  X12/DISA  Information  Manual,  fall 
1990  and  spring  1991. 
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5.3  VERSION/RELEASE  TIMING 

Identification  of  the  official  “version”  of  a  standard  is  critical 
to  the  successful  interchange  of  information.  Each  participant 
must  be  able  to  send  and  receive  the  same  version  to  ensure  the 
accuracy  of  the  information  exchanged. 

The  version  is  transmitted  as  a  12-character  code  in  the  Func¬ 
tional  Group  Header  segment  (GS)  in  Data  Element  #480, 
Version/Release/Industry  ID.  This  12-character  code  is  used  by 
ASC  X12  as  follows: 

Position  Content 

1-3  Version  number 

4-S  Release  level  of  version 

6  Subrelease 

7-12  DoD/Industry  or  Trade  Association  ID 

ASC  X12  assigns  the  codes  in  positions  1  through  6. 

A  major  version  (1-3)  will  change  only  after  an  official  public 
review  cycle,  leading  to  republication  of  a  new  American  Nadmial 
Standard. 

Release  level  of  each  new  major  version  (4-6)  will  begin  at 
“000”  and  incremented  by  1  for  each  new  ASC  X12  approved 
publication  cycle,  usually  once  a  year.  The  fifth  character 
designates  the  release  and  the  sixth  character  designates  the 
subrelease. 

DoD/Industry /Trade  Association  ID  (7-12)  is  used  to  identify 
conventions.  For  this  suffix,  DoD  will  use  “DoDO”  with  the 
10th  character  identifying  successive  publications.  The  11th  and 
12th  characters  may  be  used  by  the  Military  Departments  or 
Defense  Agencies. 

The  official  Version/Release/DoD  ID  for  this  publication  is 
included  in  the  page  number  of  the  Transaction  Sets  found  in 
Section  10.7.  For  example,  in  page  number  810.002002DoD0.1, 
the  Veisicm/Release/Dol)  ID  is  “002002DoD0.”  This  number 
may  be  different  for  each  transaction  set. 

DoD  conventions  for  using  ASC  X12  standards  are  fully  ap¬ 
proved  by  ASC  X12  and  published  annually  as  Draft  Standard 
for  Trial  Use  (DSTUs).  Conventions  developed  for  each  release 
will  be  maintained  for  4  years.  Military  Services  and  DoD 
Agencies  will  determine  which  release  to  use  on  the  basis  of 
business  need  but  will  not  use  any  release  more  than  4  years  old 
without  approval  of  the  DoD  EA. 
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5.4  PROPOSED  CHANGES 

Future  publications  of  the  implementation  guidelines  will  include 

conventions  for  the  following  DSTUs: 

•  824  Application  Advice,  which  provides  the  ability  to  report 
the  results  of  an  application  system’s  data  content  edits  of 
transaction  sets. 

•  832  Price/Sales  Catalog,  which  provides  the  format  and 
establishes  the  data  contents  of  a  price/sales  catalog  transac¬ 
tion  set. 

•  836  Contract  Award,  which  provides  the  ability  to  notify  the 
seller  or  other  interested  parties  that  the  contract  has  been 
awarded  and  that  it  contains  some  indefinite  features,  such 
as  delivery  schedule,  location,  and/or  quantities. 

•  841  Specifications/Technical  Information,  which  can  be  used 
to  exchange  a  complete  or  partial  technical  description  (text, 
graphic,  tabular,  image,  spectral,  or  audio  data)  of  a  product, 
process,  or  service  over  the  same  communication  path  as  any 
other  EDI  transaction. 


911113 


6.0  COMMUNICATIONS 


This  chapter  describes  die  conqiuter-to-conqiuter  communications 
and  contains  information  on  protocols  and  communications  options. 
It  also  presents  a  discussicm  on  the  impact  of  the  Government  Open 
Systems  Interconnection  Profile  (GOSIP)  and  the  General  Services 
Administration’s  FTS  2000  on  these  options. 

6.1  INTRODUCTION 

Two  components  of  EDI  are  the  message  standards  and  the 
communications  options  for  transmitting  those  standards.  This 
section  provides  an  overview  of  the  communications  options 
available  to  an  organization  planning  to  implemmit  EDI.  Its 
purpose  is  to  highlight  the  areas  in  which  key  data  communica* 
tions  design  decisions  must  be  made.  We  do  not  offer  any  single 
or  preferred  solution;  each  organization  must  determine  the 
proper  approach  based  on  current  and  projected  transaction 
volume  and  level  of  investment.  The  Military  Departments  and 
Defense  Agencies  have  telecommunications  networks  that  could 
provide  the  required  services  or,  at  a  minimum,  the  technical 
support  needed  to  develop  a  telecommunications  plan.  The  in* 
dustries  involved  in  the  EDI  project  must  be  consulted  early  in 
the  planning  process.  Service  requirements  beyond  the  capability 
of  Ae  DoD  parent  organization  should  be  obtained  from  the 
Defense  Information  Systems  Agency  (DISA). 

6.1.1  EDI  Communications  Network  Alternatives 

The  following  are  EDI  communicatimis  networic  alternatives: 

•  Dedicated  networks 

•  Switched  networks 

•  Network  value-added  services. 

Dedicated  networks  incorporate  point-to-point  circuits  tiiat  per¬ 
manently  connect  two  sites.  The  DISA’s  Defense  Commercial 
Telecommunications  Network  (DCTN)  is  an  example. 

Switched  networks  employ  circuit-switching,  message-switching, 
or  packet-switching  technology.  In  each,  coimections  between 
sites  are  made  by  one  or  more  switches  and  the  coimections  are 
broken  after  the  transmission  is  completed.  DISA’s  DDN  is  a 
packet-switched  network. 

Network  value-added  services  are  features  provided  by  telecom¬ 
munications  networks  in  addition  to  transporting  data.  Common 
examples  include  electronic  mail,  storage,  speed,  and  code  con¬ 
version  and  translation.  Security  can  also  be  considered  a 
valued-added  service. 
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An  organization’s  own  q>ecific  EDI  transmission  requirements, 
including  current  and  future  system  needs,  will  determine  the 
appropriate  mix  of  these  alternatives. 

6.1.2  DoO  Long-Haul  Telecommunications  Guidance 

DoD  has  determined  that  its  common  user  systems  are  “Warner- 
exempt”  and  that  the  mandatory  FTS  2000  usage  provisions  do 
not  apply.  Therefore,  long-haul  connectivity  requirements  to 
support  voice,  data,  video,  and/or  integrated  telecommunications 
will  be  satisfied  by  the  following: 

•  A  DoD  common-user  system  such  as  the  DSN,  the  DDN, 
or  a  Defense  Communication  System  (DCS)  transmission 
system  will  be  selected  as  the  first  choice  for  all  new  and 
renewed  telecommunication  acquisition  requiremmits. 

•  The  FTS.  2000  will  be  used  as  the  second  choice  when 
procuring  telecommunications  equipment  that  is  not  Warner- 
exempt  unless  DoD  can  establish  two  points  to  GSA’s 
satisfaction:  that  the  DoD  requirement  cannot  be  satisfied 
by  the  FTS  2(X)0  procurement  or  that  a  DoD  procurement 
would  be  cost-effective  and  would  not  adversely  affect  the 
cost-effectiveness  of  the  FTS  2000.  The  FTS  20(X)  would 
also  be  the  second  choice  for  Wamer-exempt  telecommunica¬ 
tions  procurement  if  it  meets  the  service  requirements  and 
is  cost-effective. 

•  The  last  choice  will  be  an  organization-unique  telecom¬ 
munications  acquisition  for  Wamer-exempt  and  unique  re¬ 
quirements  that  cannot  be  satisfied  (technically, 
operationally,  or  cost-effectively)  by  either  a  DoD  common- 
user  system  or  FTS  2000. 

6.2  PROTOCOLS 

The  options  for  sending  EDI  transactions  electronically  are 
affected  by  both  the  COSIP  and  the  CSA’s  FTS  2000  contract. 

6.2.1  The  Government  Open  Systems 
Interconnection  Profile 

GOSIP  Federal  Information  Processing  Standard  146  is  in  effect; 
it  became  compulsory  in  August  1990.  GOSIP  defines  a  common 
set  of  data  communication  protocols  which  enable  systems 
developed  by  different  vendors  to  interoperate  and  users  of 
different  applications  on  those  systems  to  exchange  information. 
GOSIP  applies  to  new  networking  systems  that  permit  com¬ 
munications  between  two  autonomous  computers.  It  is  num- 
datory  where  it  provides  the  required  communications 
functionality. 

6.2.2  General  Services  Administration's  FTS  2000 

The  FTS  2000  contract  awarded  in  December  1988  by  GSA  also 
affects  each  alternative.  FTS  2000  is  the  second  choice  for  DoD 
telecommunications.  (DoD  common-user  systems  such  as  DDN 
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are  the  first  choice.)  The  FTS  2000  services  are  available  and 
include  the  following: 

•  Circuit-switched  data  service 

•  Dedicated  transmission  service 

•  Switched  digital  integrated  service 

•  Packet-switched  service 

•  Electronic  mail. 

The  circuit-switched  data  service  will  provide  circuit-switched 
service  at  S6  Kbps  and  64  Kbps.  The  dedicated  transmission 
service  provides  the  same  data  rates  on  a  continuous  basis,  plus 
full  T1  (l.S  Mbps)  facilities.  The  integrated  services  will  come 
on  line  with  the  availability  of  ISDN.  Under  ISDN,  all  the 
services  listed  above  plus  voice  and  video  transmissions  are 
combined  on  a  single  network  and  accessed  through  the  same 
network  connection. 

6.3  POINT-TO-POINT  (DEDICATED) 
NETWORKS 

Point-to-point  circuits  connect  users  in  dedicated  networks. 
These  dedicated  facilities  are  used  when  EDI  transactions  are 
continual  between  two  points.  Since  the  users  are  paying  for  the 
link  regardless  of  the  number  of  transmissions,  its  usage  must 
be  high  for  it  to  be  economical. 

The  DISA  provides  these  circuits  on  DCTN  as  a  waiver  from 
DDN.  The  DCTN  provides  dedicated  data  circuits  in  addition 
to  switched  voice,  dedicated  voice,  and  video  communications 
for  DoD's  CONUS  operational  support  requirements.  The  ser¬ 
vices  are  provided  by  AT&T  under  a  fixed-rate,  leased  services 
contract  that  runs  through  February  1996. 

The  DCTN  incorporates  satellite  communications  as  well  as 
terrestrial  facilities. 

The  telecommunications  protocols  used  to  send  data  across  DCTN 
depend  on  the  users  at  each  end  of  the  line. 

6.3.1  Impact  of  Government  Open  Systems 
Interconnection  Profile 

GOSIP’s  X.2S  protocol  should  be  used  when  connecting  two 
distant  host  computers  through  a  dedicated  circuit.  It  provides 
a  nonproprietary  solution  although  it  is  less  efficient  than  other 
options  for  sending  data  across  a  dedicated  circuit.  It  offers  a 
smooth  transition  onto  a  packet-switched  network  if  that  becomes 
desirable. 
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6.3.2  Impact  of  FTS  2000 

The  FTS  2000  contract  provides  a  dedicated-circuit  option.  It 
offers  analog  data  circuits  at  data  transmission  rates  up  to 
4.8  Kbps  and  at  9.6  Kbps.  Digital,  synchronous,  full-di^>lex, 
service  will  be  available  at  9.6  Kbps  and  S6  Kbps  (64  Kbps  in 
the  future).  A  T1  (l.S  Mbps)  service  is  also  offered  for 
high-speed  dedicated  network  connections. 


6.4  TfflRD-PARTY  SERVICES  (SWITCHED 
NETWORKS  AND  VALUE-ADDED 
SERVICES) 

Switched  networks  connect  and  disconnect  circuits  as  required  to 
transmit  data.  The  three  common  methods  are 

•  Circuit  switching 

•  Message  switching 

•  Packet  switching. 

Circuit  switching  is  used  in  the  public  telephone  systems.  A 
circuit  is  dedicated  between  the  source  and  destination  for  the 
duration  of  the  transmission.  For  data,  as  in  telephone  calls, 
the  destination  must  be  available  before  the  connecticm  can  be 
completed. 

Message-switching  networks  package  the  data  in  messages  and 
pass  the  messages  from  switch  to  switch.  The  sender  and 
receiver  do  not  have  to  be  available  at  the  same  time  since  the 
message  is  stored  at  each  intermediate  step.  For  that  reason, 
message-switching  networks  are  also  referred  to  as  store  and 
forward  networks.  The  Automatic  Digital  Network  (AUTODIN) 
is  a  message-switching  network. 

Packet  switching  is  similar  to  message  switching,  but  it  divides 
the  data  into  smaller,  equal-size  pieces  called  packets.  It  takes 
less  time  to  move  data  through  the  network  since  large  messages 
do  not  have  to  be  stored  at  each  intermediate  switch.  The 
reduced  delay,  over  message  switching,  allows  the  two  users  to 
carry  on  a  dialog,  referred  to  as  an  interactive  process.  In 
addition,  the  reduced  delay  aids  transaction  processing  by  moving 
the  transactions  to  their  destinations  quickly. 

Packet  switching’s  advantage  over  circuit  switching  is  in  making 
efficient  use  of  the  data  lines.  Since  each  packet  carries  a 
destination  address,  packets  from  multiple  sources  heading  to 
different  destinations  can  be  transmitted  down  the  same  data  line 
if  desirable. 

The  DDN  is  a  packet-switching  network  for  DoD’s  data  com¬ 
munication  needs.  It  includes  about  2,000  hosts  with  an  es¬ 
timated  50,000  users,  and  has  a  maximum  data  rate  of  56  Klq>s. 
Although  the  data  rate  between  the  switches  may  be  increased 
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to  l.S  Mbps,  DoD  does  not  now  plan  to  increase  the  data  rates 
at  the  user  connection.  The  network  uses  TCP/IP  and  X.25 
standards.  Those  protocols  must  also  be  resident  on  each  user’s 
system  for  connection  to  the  network.  Each  user  follows  the 
same  method,  the  File  Transfer  Protocol  (FTP)  for  file  transfers, 
and  the  Simple  Mail  Transfer  Protocol  (SMTP)  for  electronic 
mail.  Each  user  can  send  and  receive  data  with  any  other 
allowed  user  who  has  a  connection  to  the  network. 

6.4.1  Impact  of  Government  Open  System  Interconnec¬ 
tion  Profile 

The  GOSIP  specifies  the  1984  International  Consultative  Com¬ 
mittee  on  Telegraphy  and  Telephony  (CCITT)  X.2S  recommen¬ 
dations  for  wide-area  communications.  ISDN  will  be 
incorporated  into  Version  2  of  the  GOSIP  as  another  alternative. 
As  with  X.2S,  ISDN  is  a  subnetwork  technology  for  siqiporting 
the  higher  level  GOSIP  protocols. 

The  DDN  implementation  of  X.25  is  based  on  the  1980  CCITT 
X.2S  recommendations.  The  DDN  standard  service  assumes  the 
use  of  the  TCP/IP  protocols  and  supports  the  following: 

•  Logical  addressing 

•  Precedence  and  preemption 

•  Additional  diagnostic  codes 

•  1822DH  and  HDH  interoperability. 

It  cannot  support  the  following: 

•  X.2S  closed  user  groups 

•  Reverse  billing 

•  Account  negotiation 

•  D-bit  modification. 

DDN  also  offers  a  basic  service  that  has  full  performance 
capabilities  and  is  compatible  with  the  commercial  and  interna¬ 
tional  networks.  The  basic  and  standard  service  cannot  be 
accessed  through  the  same  DDN  connection. 

6.4.2  Impact  of  FTS  2000 

Circuit-switched  data  service  will  be  available  at  56  Kbps 
(64  Kbps  in  the  future).  A  7-digit  numbering  plan  will  be 
employ^  by  the  prime  contractor  (AT&T  for  DoD)  for  accessing 
other  users.  The  numbering  plan  may  be  integrated  with  the 
switched-voice  numbering  plan  at  the  discretion  of  the  prime 
contractor. 

The  packet-switching  services  provided  under  FTS  2000  will 
conform  to  the  1984  CCITT  X.25  recommendations.  The  default 
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packet  size  will  be  128  bytes  but  the  size  will  be  adjustable  from 
64  to  256  bytes.  Access  will  be  through  dial-iq>  asynchronous 
connections  at  300  bps,  1.2  Kbps,  and  2.4  Kbps;  dial-up 
synchronous  connections  at  4.8  Kbps;  and  dedicated  access  at 
speeds  up  to  4.8  Kbps,  9.6  Kbps,  and  56/64  Kbps. 

The  digital  integrated  service  will  provide  both  circuit  and  packet 
switching  through  the  same  network  interface.  An  ISDN  and  a 
T1  interface  will  be  offered. 

The  basic  rate  ISDN  interface  accesses  two  64-Kbps  channels 
and  one  16-Kbps  signaling  channel.  Those  three  channels  are 
combined  to  comprise  one  basic-rate  ISDN  circuit.  The  signaling 
channel  carries  the  information  for  configuring  the  two  64-Kbps 
channels  in  either  the  circuit-switched  or  packet-switched  mode. 
Users  who  require  a  large  burst  of  data  for  EDI  can  request  a 
circuit-switched  connection.  Those  whose  needs  include  idle 
time,  such  as  an  interactive  sessions,  should  request  the  packet- 
switched  connection.  Both  are  provided  on  the  same  coimection. 

Two  different  T1  interfaces  will  be  provided  under  the  T1  portion 
of  the  Switched  Digital  Integrated  Service.  The  first  type  divides 
the  1.544-Mbps  circuit  into  24  channels.  The  second  provides 
48  switched  data  channels. 

6.4.3  Network  Value-Added  Services 

Communications  networks  now  offer  services  beyond  merely 
moving  data  from  one  site  to  another.  They  provide  electronic 
mail,  data  storage,  and  speed  and  format  conversion  or  transla¬ 
tion.  The  term  VANs  often  refers  to  the  public  data  networks 
such  as  Tymnet  and  Telenet.  Those  network  services  may  be 
provided  by  DISA,  FTS  2000,  or  the  public  data  networks. 

Electronic  mail  allows  users  to  send  text  such  as  letters  and 
memos  for  later  retrieval  by  another  network  user.  Work  is 
under  way  to  incorporate  EDI  transactions  into  an  electronic  mail 
message. 

Data  storage  is  an  auxiliary  storage  on  the  network  to  hold  files 
until  the  recipient  is  ready  to  receive  them. 

Speed  is  converted  through  the  intermediate  switches.  The  data 
are  buffered  at  each  switch  so  the  speed  at  which  the  data  enter 
the  switch  can  be  different  from  Uie  speed  at  vdiich  the  data 
leave.  That  conversion  is  possible  in  message  switching  and 
packet  switching  but  not  circuit  switching.  In  circuit  switching, 
the  sender  and  receiver  are  connected  and  must  operate  at  the 
same  speed. 

In  format  conversion,  the  data  are  translated  from  the  sender’s 
format  to  the  receiver’s  format.  For  EDI  participants,  that 
conversion  may  mean  translating  from  a  non-EDI  format  to  EDI 
before  sending  the  data  to  the  destination.  The  conversion  may 
also  take  place  between  two  similar  applications,  such  as  from 
one  electronic  mail  system  to  another.  Two  examples  are  the 
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application  layer  gateways  that  will  be  placed  on  DDN  to  handle 
messages  going  between  SMTP  and  message  handling  systems 
(MHS)  and  files  between  FTP  and  File  Transfer,  Access,  and 
Management  Protocol  (FTAM)  systems. 

6.5  NETWORK  INTERCONNECTIONS 

Most  industries  have  contracted  with  commercial  networic  {nxmders 
for  a  variation  of  the  alternatives  rather  than  develop  their  own 
networks.  Most  of  die  networic  providers  have  qiecialized  in  the 
following  EDI  services: 

•  Data  standard  support 

•  Translation  software 

•  Protocol  conversion 

•  Mailbox  service 

•  Network  billing. 
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7.0  DoD  BUSINESS  MODELS 

This  chapter  presents  a  narrative  describing  how  EDI  functions 
within  several  business  areas.  These  examples  are  provided  to 
assist  you  in  developing  your  own  applications. 

7.1  GENERAL  BUSINESS  MODEL 

The  model  shown  in  Figure  7.1-1  depicts  the  logical  flow  of 
EDI  transaction  sets  (data)  that  have  DoD  conventions.  The 
model  will  be  updated  as  new  conventions  are  added. 

7.2  SMALL  BUSINESS  MODEL  (to  be  published) 

7.3  ORDERING  SUPPLIES  OR  SERVICES 

There  are  two  basic  categories  of  electronic  purchase  orders: 
purchase  orders  issued  against  existing  contracts  and  individual 
purchases.  The  models.  Figures  7.3-1  and  7.3-2,  are  at  the 
highest  level  of  data  flow  and  are  meant  to  convey  concepts 
which  can  be  expanded  upon  and  implemented. 

7.3.1  Indefinite  Delivery  Contracts 

Multi-item  indefinite  delivery  contracts  usually  result  in  the  estab¬ 
lishment  of  a  multi-year  business  relationship  with  a  commercial 
vendor  and  create  an  ideal  environment  for  EDI.  Figure  7.3-1 
depicts  the  logical  data  flow  associated  with  ordering  supplies  and 
services  using  EDI  in  support  of  a  multi-item  indefinite  delivery 
contract.  Purchase  orders,  using  transaction  850,  are  issued  by  DoD 
against  the  contract  as  material  is  required.  A  purchase  order 
acknowledgment  (transaction  855)  is  returned  by  the  vendor  to 
confirm  acceptance  of  each  order.  When  the  material  is  shipped, 
a  ship  notice  (transaction  856)  is  sent  by  the  vendor  to  DoD  followed 
by  an  invoice  (transaction  810).  Upon  notice  of  receipt  (transaction 
861)  DoD  would  initiate  an  EFT  payment  and  payment  order/remit¬ 
tance  advice  (transaction  820).  Functional  acknowledgments  (trans¬ 
action  997)  are  returned  by  DoD  and  vendor  during  the  exchanges 
to  provide  a  positive  response  that  the  contents  of  the  transmission 
were  ANSI  ASC  X12  syntactically  correct. 

7.3.2  Individual  Purchases 

Although  more  complex,  EDI  can  be  used  to  purchase  common 
items  whose  specifications  are  well  known  to  both  DoD  and 
vendor.  Figure  7.3-2  depicts  the  logical  data  flow  where  there 
is  no  contract.  The  DoD  sends  a  RFQ  (transaction  840)  to  one 
or  more  vendors.  The  vendors  respond  with  a  quote  (transaction 
843).  The  DoD  then  sends  a  purchase  order  (transaction  850)  to 
the  vendor  of  choice.  The  vendor  acknowledges  (transaction  855) 
to  confirm  acceptance.  When  the  material  is  shipped,  the  vendor 
sends  a  notice  (transaction  856)  to  DoD  followed  by  an  invoice 
(transaction  810).  Upon  notice  of  receipt  (transaction  861),  DoD 
initiates  an  EFT  payment  and  payment  order/remittance  advice 
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Figure  7.1-1  General  Business  Models 
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Figure  7.3-1  Indefinite  Delivery  Contract 
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(transaction  820).  Functional  acknowledgments  (transaction  997) 
are  returned  by  DoD  and  vendor  during  the  exchanges  to  provide 
a  positive  response  that  the  contents  of  the  transmission  were 
ANSI  ASC  X12  syntactically  correct. 

7.4  COMPUTER-AIDED  ACQUISITION  AND 
LOGISTIC  SUPPORT  (CALS) 

EDI  and  CALS  are  complementary  programs  to  siq>port  the 
development  of  standards  that  enable  computer  systems  to  ex¬ 
change  digital  data. 

In  a  26  July  1990  letter  to  the  National  Security  Industrial 
Association,  the  ASD(P&L)  stated 

DoD  Rcognizet  the  impoiUnce  to  both  indiutry  and  DoD  of 
being  able  to  reqtond  to  both  CALS  and  EDI  requiiemenU 
with  a  single  integrated  system.  We  are  pursuing  common 
technical  solutions  for  interchanging  CALS  and  EDI  infor¬ 
mation.  We  are  supporting  provisions  for  including  CALS 
data  within  EDI  transactions  and  are  committed  to  the  use 
of  EDI  transactions  in  CALS  whenever  appropriate. 

Progress  has  been  made  by  the  EDI  and  CALS  Government  and 
industry  groups  on  die  integration  of  the  intiadves.  Figure  7.4-1  is 
a  proposed  model  of  a  CAL/EDI  relationship.  The  specifications/ 
technical  informtion  transaction  set  can  be  used  to  transmit  CALS 
Automated  Interchange  of  Technical  Information  (MIL-STD-1840A) 
data  specifications,  or  technical  information  between  trading 
partners.  It  can  also  be  used  by  EDI  trading  partners  to  exchange 
a  complete  or  partial  technical  description  of  a  product,  process, 
service,  etc.,  over  the  same  path  as  any  other  EDI  transaction.  The 
detailed  data  can  include  graphic,  text,  parametric,  tabular,  image, 
spectral,  or  audio  data. 

Transaction  set  841  was  designed  to  be  used  in  conjunction  with 
other  EDI  general  business  transactions  in  a  standard  EDI  trans¬ 
mission.  A  DoD  convention  is  being  developed  for  its  use  and 
will  be  published  in  the  next  release  of  Ae  Implementation 
Guidelines. 

7.5  ELECTRONIC  FUNDS  TRANSFER 
CORPORATE  TRADE  EXCHANGE 
RULES 

The  Department  of  Defense  is  a  participant  in  the  Vendor  Express 
program  managed  by  Financial  Management  Services  (FMS),  a 
bureau  of  the  Department  of  the  Treasury.  Vendor  Express  is 
a  generic  term  used  to  describe  the  conversion  of  the  Federal 
Government’s  vendor  and  miscellaneous  payments  to  the 
Automated  Clearing  House  (ACH)  network. 

The  ACH  network  provides  a  reliable  payment  mechanism  that 
eliminates  problems  with  lost,  stolen,  or  forged  checks.  The 
payments  are  deposited  directly  to  the  vendor’s  financial  institution 
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Figure  7.4-1  CALS/EDI  X12  Standards  Relationship 
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account  on  the  payment  date  utilizing  the  National  Automated 
Clearing  House  Association  (NACHA)  rules. 


A  key  feature  of  the  program  is  the  use  of  addenda  records 
utilizing  EDI  (ANSI  ASC  X12  standards)  to  transmit  accounting 
information  with  the  payment. 

The  combination  of  payment  and  payment  information  allows  the 
vendor  to  apply  this  information  upon  receipt  and  saves  recon¬ 
ciliation  time.  In  general,  EDI  provides  a  basis  for  complete 
end-to-end  automation  of  order  entry  information. 

There  are  two  corporate  (vendor)  ACH  standard  entry  classes 
which  may  utilize  EDI  in  the  addenda  record:  CCD-Plus  and 
CTX. 

•  Cash  Concentration  or  Disbursement  entry  with  a  Special 
Addenda  Record,  or  “CCD-Plus" 

For  CCD-Plus  entries,  only  one  addenda  record  may  accom¬ 
pany  each  entry  and  is  restricted  to  80  characters  of  ASC 
X12.4,  Payment  Order/Remittance  Advise  data  segments  and 
elements.  (Single  payment,  single  invoice.) 

•  Corporate  Trade  Exchange,  or  CTX. 

For  CTX  entries.  Figure  7.S-1,  more  payment  informatioD  can 
be  relayed  by  uring  the  hiU  capabilities  of  die  EDI  standard. 
(Single  payment,  multiple  invoice.) 

7.5.1  Payment  Information  Process 

In  Figure  7.5-2,  the  vendor  (contractor)  bills  the  DoD  activity 
for  the  goods/services  provided.  The  DoD  activity  authorizing 
the  payment  forwards  Uie  payment  and  the  payment  information 
to  ^S  Regional  Finance  Center.  The  center  forwards  the 
payment  and  accompanying  information  to  the  appropriate 
Federal  Reserve  Bank. 

The  Federal  Reserve  Bank  forwards  the  payment  and  accompany¬ 
ing  information  to  the  vendor’s  financial  institution.  The  finan¬ 
cial  institution  deposits  the  payment  in  the  vendor’s  account  and 
forwards  the  payment  information  to  the  vendor. 

7.5.2  Potential  Benefits  of  EFT/EDi 

All  participants  (vendors,  financial  insfibjtions,  and  DoD)  have 
the  potential  to  benefit  from  EFT/EDI.  In  addition  to  the  usual 
benefits  of  EDI  (see  Chapter  1 ,  Section  4)  there  are  some  specific 
areas  such  as  the  elimination  of  lost,  stolen,  or  forged  checks 
that  result  directly  from  EFT/EDI. 

Vendors  can  expect  to  benefit  from  having  usable  funds  <mi  the 
payment  day.  This  certainty  of  funds  can  have  a  significant 
impact  on  other  financial  transactions.  Disputes  due  to  mail 
delays  will  also  be  a  thing  of  the  past.  With  the  data  available 
in  a  form  easily  integrated  into  other  internal  systems  such  as 
accounts  receivable,  there  should  be  a  reduction  in  the  cost  of 
manual  processing  and  paper  handling. 
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Figure  7.5-1  Diagram  of  Sequence  of  Records  for  CTX  Entries 
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Figure  7.5-2  EFT/EDI  -  Dollars  and  Data  Together 
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Financial  institutions  will  also  benefit  from  the  increased  level 
of  automation.  They  have  the  opportunity  to  become  more 
responsive  to  their  customer’s  needs  by  providing  additional  cash 
management  and  transaction  processing  services. 

For  DoO  and  the  Federal  Government,  EFT/EDI  provides  a  less 
expensive  method  of  payment.  The  Department  of  the  Treasury 
estimated  the  cost  to  issue  a  check  was  reduced  by  26  cents 
through  the  use  of  EFT/EDI.  In  1989,  this  saved  the  U.S. 
taxpayers  $90  million.  The  increase  in  automation  also 
strengthened  payment  and  accounting  controls  and  boosted 
productivity.  Over  1  million  payments  were  issued  per  regional 
finance  center  employee  in  1989. 

The  EFT/EDI  provides  all  participants  an  opportunity  to 
reexamine  their  approach  to  financial  management  and  change  to 
benefit  their  customers  and  themselves. 

7.5.3  Implementation  Issues 

Not  all  Military  Service  organizations  or  Defense  Agencies  have 
the  capability  to  pay  using  EFT,  but  this  is  rapidly  changing. 

A  schedule  of  DoD  activities  currently  or  projected  to  have 
EFT/EDI  capability  can  be  obtained  from  the  Department  of  the 
Treasury,  Marketing  Branch,  Payments  Management  Division, 
Washington,  DC  20227. 

7.5.4  How  to  Get  Started 

DoD  vendor’s  wishing  to  participate  in  the  Vendor  Express 
program  should  first  contact  the  Military  Service  organization  or 
Defense  Agency  with  which  it  does  business.  The  DoD  organize* 
tion  will  provide  additional  information  and  assistance.  The  first 
step  is  to  complete  the  “Company  Infonnation”  section  of  the 
—  Standard  Form  3881,  “Payment  Information  Form,”  provided 
by  the  DoD  activity. 

This  form  is  then  taken  to  the  vendor’s  financial  institution. 
Agreement  must  be  reached  as  to  how  the  payment  infonnation 
(addendum)  will  be  provided  to  the  vendor.  This  could  be  by 
customer’s  statement,  magnetic  tape,  on-line  query,  or  telephone. 
EDI  is  the  preferred  method  if  your  internal  accounting  processes 
are  automated  to  take  advantage  of  direct  entry  of  data.  The 
financial  institution’s  ACH  coordinator  will  then  complete  the 
“Financial  Institution”  portion  of  the  form.  The  vendor  should 
then  return  the  form  to  the  DoD  activity  they  are  doing  business 
with. 

The  DoD  activity  will  coordinate  with  all  participants  to  complete 
the  technical  requirements  and  testing.  Production  will  begin 
after  successful  testing  and  with  the  approval  of  all  participants. 
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8.0  GLOSSARY 

This  chapter  contains  ASC  X12  and  DoD  specific  glossaries. 

8.1  X12  GLOSSARY 

AlA 

Aerospace  Industry  Association 
AIAG 

Automotive  Industry  Action  Group 
AISI 

American  Iron  and  Steel  Institute 
ANSI 

American  National  Standards  Institute 
ANSI  Standard 

A  document  published  by  ANSI  that  has  been  approved  through 
the  consensus  process  of  public  announcement  and  review.  Each 
of  these  standards  must  have  been  developed  by  an  ANSI 
committee  and  must  be  revisited  by  that  committee  within  5  years 
for  update.  See  Draft  Standard  for  Trial  Use  (DSTU). 

API 

American  Paper  Institute;  American  Petroleum  Institute 
Application  Acknowledgment 

A  transaction  set  whose  purpose  is  to  return  a  response  to  a 
transaction  set  that  has  been  received  and  processed  in  an 
application  program.  The  Purchase  Order  Acknowledgment 
Transaction  Set  855  is  an  example  of  an  application  acknowl¬ 
edgment.  It  is  used  to  respond  to  the  Purchase  Order  Transaction 
Set  850  presenting  such  things  as  whether  the  receiver  can  fulfill 
the  order  and  if  it  can  be  done  on  time. 

Application  Advice  (824) 

A  transaction  set  that  accepts,  rejects,  or  identifies  errors  in  the 
content  of  any  transaction  set  beyond  the  normal  syntax  checks. 

Area  Transaction  Set 

Identifies  a  predefmed  area  within  a  transaction  set  (header, 
detail,  summary)  containing  segments  and  their  various  attributes. 
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ASC  X12 

Accredited  Standards  Committee,  X12  comprises  industry  mem¬ 
bers  who  create  EDI  standards  for  submission  to  ANSI  for 
subsequent  approval  and  dissemination;  or  for  submission  to  the 
UN/ECE  for  approval  and  submission  of  UN/EDIFACT  stan¬ 
dards. 

ATA 

American  Trucking  Association;  Air  Transport  Association 
Authentication 

A  mechanism  which  allows  the  receiver  of  an  electronic  trans¬ 
mission  to  verify  the  sender  and  the  integrity  of  the  content  of 
the  transmission  through  the  use  of  an  electronic  “key”  or 
algorithm  which  is  shared  by  the  trading  partners,  lliis  is 
sometimes  referred  to  as  an  electronic  signature. 

BSR 

Bureau  of  Standards  Review 
CEC 

Commission  of  the  European  Communities 
CIDX 

Chemical  Industry  Data  Exchange 
CMEA 

Council  for  Mutual  Economic  Assistance 
Compliance  Checking 

A  checking  process  that  is  used  to  ensure  that  a  transmission 
complies  with  ANSI  X12  syntax  rules. 

Composite  Data  Element 

One  or  more  component  data  elements  delimited  by  subelement 
separators.  Currently,  this  is  used  only  in  the  EDIFACT  stan¬ 
dards. 

Conditional  (C) 

A  data  element  requirement  designator  which  indicates  that  the 
presence  of  a  specified  data  element  is  dependent  on  the  value 
or  presence  of  other  data  elements  in  the  segment.  The  condition 
must  be  stated  and  must  be  computer  processable. 

Control  Segment 

A  Control  Segment  has  the  same  structure  as  a  Data  Segment 
but  is  used  for  transferring  control  information  for  grouping  data 
segments.  Control  Segments  are  Loop  Control  Segments 
(LS/LE),  Transaction  Set  Control  Segments  (ST/SE),  and  Func¬ 
tional  Group  Control  Segments  (GS/GE),  de^ed  in  X12.6,  and 
Interchange  Control  Segments  (ISA/IEA/TAl)  defined  in  X12.5. 
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Control  Validation 

Confirmation  that  information  within  the  control  segments  is 
correct. 

Data  Element 

The  basic  units  of  information  in  the  EDI  standards  containing 
a  set  of  values  that  represent  a  singular  fact.  They  may  be 
single-character  codes,  literal  descriptions,  or  numeric  values. 

Data  Element  Length 

This  is  the  range,  minimum  to  maximum,  of  the  number  of 
character  positions  available  to  represent  the  value  of  a  data 
element.  A  data  element  may  be  of  variable  length  with  range 
from  minimum  to  maximum,  or  it  may  be  of  fixed  length  in 
which  the  minimum  is  equal  to  the  maximum.  (X12.3) 

Data  Element  Reference  Number 

Reference  number  assigned  to  each  data  element  as  a  unique 
identifier. 

Data  Element  Requirement  Designator 

A  code  defining  the  need  for  a  data  element  value  to  appear  in 
the  segment  if  the  segment  is  transmitted.  The  co^  are 
mandatory  (M),  optional  (O),  or  conditional  (C). 

Data  Element  Separator 

A  unique  character  preceding  each  data  element  that  is  used  to 
delimit  data  elements  within  a  segment. 

Data  Element  Type 

A  data  element  may  be  one  of  six  types:  numeric,  decimal, 
identifier,  string,  date,  or  time. 

Delimiters 

The  delimiters  consist  of  two  levels  of  separators  and  a  ter¬ 
minator.  The  delimiters  are  an  integral  part  of  the  transferred 
data  stream.  Delimiters  are  specified  in  the  interchange  header 
and  may  not  be  used  in  a  data  element  value  elsewhere  in  the 
interchange.  From  highest  to  lowest  level,  the  separators  and 
terminator  are  segment  terminator,  data  element  separator,  and 
subelement  separator  (only  used  in  EDIFACT). 

DISA 

Data  Interchange  Standards  Association.  A  nonprofit  organiza¬ 
tion  funded  by  X12  which  serves  as  the  Secretariat  for  X12. 

Direct  Transmission 

The  exchange  of  data  from  the  computer  of  the  sending  party 
directly  to  the  computer  of  the  receiving  party.  A  third-party 
value-added  service  is  not  used  in  a  direct  transmission. 
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DSTU 

Draft  Standard  for  Trial  Use.  Represents  a  document  approved 
for  publication  by  the  lull  X12  committee  following  memtership 
consensus  and  subsequent  resolution  of  negative  votes.  (Final 
Report  of  X12  Publications  Task  Group).  The  Draft  EDI  Stan¬ 
dard  for  Trial  Use  document  represents  an  ASC  X12  approved 
standard  for  use  prior  to  approval  by  ANSI.  See  ANSI  Standard. 

EB 

The  EDIFACT  Board 
EBCIDIC 

Extended  binary-coded-decimal  interchange  code 
EC 

European  Community;  electronic  commerce 
EDI 

Electronic  Data  Interchange.  The  computer  application  to  com¬ 
puter  application  exchange  of  business  information  in  a  standard 
format. 

EDICC 

Electronic  Data  Interchange  Council  of  Canada 
EDIFACT  Board 

Advisory  and  Support  Team  for  a  number  of  the  UN/EDIFACT 
Rapporteurs 

EDI  Translation 

The  conversion  of  application  data  to  and  from  the  XI 2  standard 
format 

EDI  Translator 

Computer  software  used  to  perform  the  conversion  of  application 
data  to  and  from  the  X12  standard. 

EDX 

Electrical  Data  Exchange 
EFTA 

European  Free  Trade  Association  (Austria,  Finland,  Iceland 
Norway,  Sweden,  and  Switzerland) 

EIDX 

Electronics  Industry  Data  Exchange 
Electronic  Envelope 

Electronic  information  which  b'nds  together  a  set  of  transmitted 
documents  being  sent  from  one  sender  to  one  receiver. 
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Element  Delimiter 

A  single-character  which  follows  the  segment  identifier  and 
separates  each  data  element  in  a  segment  except  the  last. 

Electronic  Mailbox 

A  term  used  to  refer  to  the  place  where  an  EDI  transmission  is 
stored  for  pickup  or  delivery  within  a  third-party-service 
provider’s  system.  Trading  partners  can  also  nuintain  mailboxes 
within  their  own  domains. 

EM 

Electronic  Mail 
Encryption 

A  process  of  transforming  clear  text  (data  in  its  original,  un¬ 
encrypted  form)  into  ciphertext  (encryption  output  of  a  cryp¬ 
tographic  algorithm)  for  security  or  privacy.  (Security 
Transaction  Set  815). 

FASLINC 

Fabric  and  Suppliers  Linkage  Council 
Functional  Acknowledgment 

A  transaction  set  (997)  transmitted  by  the  receiver  of  an  EDI 
transmission  to  the  sender,  indicating  receipt  and  syntactical 
acceptability  of  data  transmitted  according  to  the  ASC  X12 
standards.  The  functional  acknowledgment  allows  the  receiving 
party  to  report  back  to  the  sending  party  problems  encountered 
by  the  syntax  analyzer  as  the  data  are  interpreted.  It  is  not 
intended  to  serve  as  an  acknowledgment  of  data  content.  See 
also  X12.6. 

Functional  Group 

A  group  of  one  or  more  transaction  sets  bounded  by  a  functicmal 
group  header  segment  and  a  functional  group  trailer  segment. 

Functional  Group  S^ments 

GS/GE  segments  identify  a  specific  functional  group  of  docu¬ 
ments  such  as  purchase  orders. 

GCA 

Graphic  Communication  Association 
GEl  • 

UN/ECE  WP4  Group  of  Experts  I  for  Data  Elements  and 
Automatic  Data  Transfer 

GE2 

UN/ECE  WP4  Group  of  Experts  2  for  Procedures  and  Documen¬ 
tation 

Hexadecimal 

Base  16  notation  commonly  used  to  represent  binary  value 
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HIBCC 

Health  Industry  Business  Conununications  Council 
Industry  Conventions 

Defines  how  the  ASC  X12  standards  are  used  by  the  specific 
industry 

Industry  Guidelines 

Defines  the  EDI  environment  for  using  conventions  within  an 
industry.  It  provides  assistance  on  how  to  implement  X12 
standards. 

Interchange  Control  Segments 

ISA/IEA  segments  identify  a  unique  interchange  being  sent  from 
one  sender  to  one  receiver  (see  electronic  envelope). 

Interchange  Control  Structure 

The  interchange  header  and  trailer  segments  envelop  one  or  more 
functional  groups  or  interchange-related  control  segments  and 
perform  the  following  functions:  (1)  defines  the  data  element 
separators  and  the  data  segment  terminators,  (2)  identifies  the 
sender  and  receiver,  (3)  provides  control  information  for  the 
interchange,  and  (4)  allows  for  authorization  and  security  infor¬ 
mation.  (X12.5) 

IPT 

International  Project  Team.  Advisory  and  Support  Team  of  the 
UN/EDIFACT  Rapporteur  for  North  America. 

ISO 

International  Standards  Organization 
JIT 

Just  in  Time.  JIT  is  the  concept  of  reducing  inventories  by 
working  closely  with  one’s  suppliers  to  coordinate  delivery  of 
materials  just  before  their  use  in  the  manufacturing  process. 

Loop 

A  group  of  semantically  related  segments;  these  segments  may 
be  either  bounded  or  unbounded  (X12.6).  The  N1  loop  is  an 
example  of  a  loop,  which  includes  segments  N1  to  PER  for  name 
and  address  information. 

Mandatory  (M) 

A  data  element/segment  requirement  designator  which  indicates 
the  presence  of  a  specified  data  element  is  required. 

Mapping 

The  process  of  identifying  the  standard  data  element’s  relation¬ 
ship  to  application  data  elements. 
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Max  Use 

Specifies  the  maximum  number  of  times  a  segment  can  be  used 
at  the  location  in  a  transaction  set 

Message 

Entire  data  stream  including  the  outer  envelope 
NACHA 

National  Automated  Clearing  House  Association 
NPTA 

National  Paper  Trade  Association 
Optional  (O) 

A  data  element/segment  requirement  designator  which  indicates 
the  presence  of  a  specified  data  element/segment  is  at  the  option 
of  the  sending  party  which  can  be  based  on  the  mutual  agreement 
of  the  interchange  parties. 

prox 

Petroleum  Industry  Data  Exchange 
Proprietary  Format 

A  data  format  specific  to  a  company,  industry,  or  other  limited 
group.  Proprietary  formats  do  not  comply  with  the  ASC  X12 
series  of  standards. 

Qualifier 

A  data  element  which  identifies  or  defines  a  related  element,  set 
of  elements,  or  a  segment.  The  qualifier  contains  a  code  taken 
from  a  list  of  approved  codes. 

Rapporteur 

An  individual  expert  appointed  by  the  United  Nations  for  specific 
objectives 

Repeating  Segment 

A  segment  that  may  be  used  more  than  once  at  a  given  location 
in  a  transaction  set.  See  Max  Use. 

SAFLINC 

Sundries  and  Apparel  Findings  Linkage  Council 
S.C.C.  JTC/EDl 

Standards  Council  of  Canada  Joint  Technical  Committee  on 
Electronic  Data  Interchange 

Security 

System  screening  which  denies  access  to  unauthorized  users  and 
protects  data  from  unauthorized  uses 
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S^ment 

Segments  consist  of  logically  related  data  elements  in  a  defined 
sequence.  A  data  segment  consists  of  a  segment  identifier,  one 
or  more  data  elements  each  preceded  by  an  element  separator, 
and  ends  with  a  segment  terminator.  (X12.6) 

Segment  Directory  (X12.22) 

Provides  the  purpose  and  format  of  the  segments  used  in  the 
construction  of  transaction  sets.  The  directory  lists  each  segment 
by  name,  purpose,  identifier,  the  contained  data  elements  in  the 
specified  order,  and  the  requirement  designator  for  each  data 
element. 

Segment  Identifier 

A  unique  identifier  for  a  segment  composed  of  a  combination  of 
two  or  three  upper-case  letters  and  digits.  The  segment  identifier 
occupies  the  first-character  positions  of  the  segment.  The  seg¬ 
ment  identifier  is  not  a  data  element.  The  segment  identifier  in 
EDIFACT  is  a  component  data  element  —  part  of  a  composite 
data  element  consisting  of  a  segment  identifier  and  an  explicit 
looping  designator. 

Segment  Terminator 

A  unique  character  appearing  at  the  end  of  a  segment  to  indicate 
the  termination  of  the  segment. 

Subelement  Separator 

A  unique  character  used  to  delimit  the  component  data  elements 
within  a  composite  data  element  (only  used  in  EDIFACT). 

Syntax 

The  grammar  or  rules  which  define  the  structure  of  the  EDI 
standards  (i.e.,  the  use  of  loops,  qualifiers,  etc.).  Syntax  rules 
are  published  in  ANSI  X12.6. 

TALC 

Textile/Apparel  Linkage  Council 
TAMCS 

Textiles/Apparel  Manufacturing  Communications  Standards 
TCIF 

Telecommunications  Industry  Forum 
TDCC/EDIA 

The  Transportation  Data  Coordinating  Conunittee/EIectronic  Data 
Interchange  Association 

TEDIS 

Trade  Electronic  Data  Interchange  Systems.  A  program  of  the 
CEC. 
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Trading  Partner 

The  sending  and/or  receiving  party  involved  in  the  exchange  of 
electronic  data  interchange  transmissions. 

Transaction  Set 

The  transaction  set  unambiguously  defines,  in  the  standard  syn¬ 
tax,  information  of  business  or  strategic  significance  and  consists 
of  a  transaction  set  header  segment,  one  or  more  data  segments 
in  a  specified  order,  and  a  transaction  set  trailer  segment. 

Transaction  Set  ID 

An  identifier  that  uniquely  identifies  the  transaction  set.  This 
identifier  is  the  first  data  element  of  the  transaction  set  header 
segment. 

Translation 

The  act  of  accepting  documents  in  other  than  standard  format 
and  translating  them  to  the  standard. 

ucc 

Uniform  Code  Council 

ucs 

Uniform  Communication  Standard 

UISG 

Utilities  Industry  Standards  Group 

UN/ECE 

United  Nations/Economic  Commission  for  Europe 
UNSM 

A  standard  message  to  be  used  in  electronic  data  interchange 
(EDI)  between  business  partners  which  has  been  registered  with 
the  UN/ECE  WP4. 

UNTDED 

United  Nations  Trade  Data  Elements  Directory  standards  for  data 
fields 

VAN 

Value-added  network.  Third-party  service  organizations. 
Version/Release 

Identifies  the  publication  of  the  standard  being  used  for  the 
generation  or  the  interpretation  of  data  in  the  X12  standard 
format.  May  be  found  in  the  Functional  Group  Header  Segment 
(GS)  and  in  the  Interchange  Control  Header  Segment  (ISA).  See 
Control  Segment. 

Vies  Committee 

Voluntary  Interindustry  Communications  Standards  for  Electronic 
Data  Interchange 
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WINS 

Warehouse  Industry  National  Standards  guidelines 
WP4 

United  Nations  Trade  Working  Party  4  on  Facilitation  of  Inter¬ 
national  Trade  Procedures.  Responsible  among  others,  for  various 
initiatives  on  EDI. 

X12 

The  ANSI  committee  responsible  for  the  development  and  main¬ 
tenance  of  standards  for  electronic  data  interchange  (EDI). 

X12.5 

Interchange  Control  Structure.  This  standard  provides  the  inter¬ 
change  envelope  of  a  header  and  trailer  for  the  electronic 
interchange  through  a  data  transmission,  and  it  provides  a  struc¬ 
ture  to  acknowledge  the  receipt  and  processing  of  this  envelope. 

X12.6 

Application  Control  Structure.  This  standard  describes  the  con¬ 
trol  segments  used  to  envelop  loops  of  data  segments,  to  envelop 
transaction  sets,  and  to  envelop  groups  of  related  transaction  sets. 

8.2  DoD  GLOSSARY 

ACH 

Automated  Clearing  House 
AIS 

Automated  Information  Systems 
ASCENT 

Control  Data  Corporation’s  conunercial  version  of  Lawrence 
Livermore  National  Laboratory’s  Intelligent  Gateway  Processor 

ASD(P&L) 

Assistant  Secretary  of  Defense  (Production  and  Logistics) 
AUTODIN 

Automatic  Digital  Network 
BCAS 

Base  Contracting  Automated  System 
BNR 

Bell  Northern  Research 
CAD 

Computer  Aided  Design 
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CALS 

Computer-Aided  Acquisition  and  Logistic  Support 
CAM 

Computer  Aided  Manufocturing 
CCD 

Cash  Concentration  or  Disbursement 
CCITT 

International  Consultative  Committee  on  Telegraphy  and 
Telephony 

CDC 

Control  Data  Corporation 
CFR 

Code  of  Federal  Regulations 
CSM 

Computer  Security  Monitor 
CTX 

Corporate  Trade  Exchange 
DARPA 

Defense  Advance  Research  Projects  Agency 
DCS 

Defense  Communication  System 
DCTN 

Defense  Commercial  Telecommunication  Network 
DON 

Defense  Data  Network 
DepSecDef 

Deputy  Secretary  of  Defense 
DES 

Data  Encryption  Standard 
DFARS 

DoD  FAR  Supplement 
DISA 

Defense  Information  Systems  Agency 
DLA 

Defense  Logistics  Agency 
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DLMS 

Defense  Logistics  Management  System 


DLSS 

Defense  Logistics  Standard  Systems 
DSN 

defense  switched  network 
DTEDI 

Defense  Transportation  EDI 
ECON 

EC  Operational  Network 
ECTN 

Electronic  Commerce  Test  Network 
EFT 

electronic  funds  transfer 
ERS 

evaluation  receipt  settlement 
FAR 

Federal  Acquisition  Regulation 
Federal  Rules  of  Evidence 

Rules  governing  proceedings  in  the  Courts  of  the  United  States, 
especially  as  to  what  information  may  be  admissible  before  the 
Courts. 

FMS 

Financial  Management  Service 
FOIA 

Freedom  of  Information  Act 
FT  AM 

File  Transfer,  Access,  and  Management  Protocol 
FTP 

File  Transfer  Protocol 
GAO 

General  Accounting  Office 
GOSIP 

Government  Open  Systems  Interconnection  Profile 
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lAB 

Internet  Activities  Board 
ID 

Identifier 

IGP 

intelligent  gateway  processor 
IOC 

initial  operational  capability 

IP 

internet  protocol 

IRM 

Information  Resource  Management 
ISA 

Interchange  Control  Header  Identifier 
ISDN 

Integrated  Service  Digital  Network 
IWSDB 

Integrated/Distribution  Weapon  System  Data  Base 
LCM 

life>cycle  management 
LLNL 

Lawrence  Livermofp  National  Laboratory 
LRAM 

Livermore  Risk  Assessment  Methodology 
LSA 

Logistics  Support  Analysis 
MHS 

message  handling  systems 
MLS 

multi-level  secure 
MRP 

manufacturing  resource  planning 
MODELS 

Modernization  of  Defense  Logistics  Standard  Systems 
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NARA 

National  Archives  and  Records  Administration 
NIST 

National  Institute  of  Standards  and  Technology 
NTE 

Note  Identifier 
OPN 

Operational  Pilot  Network 
PC 

personal  computer 
PDES 

product  data  exchange  specification 
PDSO 

Packet  Data  Security  Overlay 
PEM 

Privacy  Enhanced  Mail 
PKC 

Public  Key  Cryptography 
PLUS 

Protection  of  Logistics  Unclassified/Sensitive  Systems 
PUB 

Publication 

QAR 

Quality  Assurance  Report 

RFP 

Request  for  Proposals 
RFQ 

Request  for  Quotations 
R&M 

reliability  and  maintainability 
RSA 

Rivest-Shamir-Adleman 

SMTP 

Simple  Mail  Transfer  Protocol 
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SNA 

System  Network  Architecture 
TCP 

Transmission  Control  Protocol 
TCP-IP 

Transmission  Control  Protocol-Internet  Protocol 
TDPEM 

Toolkit  for  Internet  Privacy  Enhanced  Mail 
TIS 

Trusted  Information  Systems 
TM 

Trusted  Mail 
TPA 

Trading  Partner  Agreement 
UN/EDIFACT 

EDIFACT;  Electronic  Data  Interchange  for  Administration,  Com¬ 
merce,  and  Transport 

USAF 

United  States  Air  Force 
WORM 

Write  Once  Read  Many 
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9.0  FORMS  AND  DOCUMENTS 


This  chapter  contains  selected  excerpts  from  the  Fall  1990 
Information  Manual  and  the  Spring  1991  Information  Manual. 
The  excerpted  material  is  used  with  permission  of  the  Data 
Interchange  Standards  Association,  Inc.  In  this  chapter,  we  first 
present  the  applicable  ASC  X12  forms.  The  initial  section. 
Introduction,  gives  the  background  of  ANSI,  ASC  X12,  and  the 
Data  Interchange  Standards  Association.  Following  that,  we 
present  the  ASC  XI 2  Organization,  the  ASC  XI 2  Standards 
Process,  and  finally,  the  Standards  Background. 
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VIII  -  FORMS,  FORMS,  FORMS 


ASC  X12  Work  Request  Form 

ASC  X12  New  Project  Proposal  Form 

ASC  X12  New  Transaction  Set  Development  Form 

Form  for  New  or  Revised  Appendix  A  Code  Source  Reference 

Document  Preparation  for  Interpretations,  Guidelines  and  Control  Standards 

Sample  Transmittal  Form 

ASC  X12  Ballot  Comment  Response  Letter  Format 
ASC  X12  Standards  Order  FOrm 
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5/10/90  DM  NUMBER _ 

DATE  SUBMITTED  (Stcrttartat  Only) 

-  ASCX12 

WORK  REQUEST  FORM 

ALL  REQUESTS  MUST  BE  TYPED  or  printad  legibly  in  black  Ink.  Complete  both  sides. 

1.  TO  USE  THIS  FORM  FOR  SUPPORTINQ  DATA  MAINTENANCE  FOR  ANEW  DRAFT  STANDARD  OR  X12  INTERPRETATION,  IM  an 
raquirwnamonONEtoan.  um  Maehmantt  m  MoMtafy.  Uat  flrat  aN  naw  aagmania,  Fian  aN  naw  data  aiamania/eodaa/eoda  aoureaa. 
Than  Hat  raviaiona  to  aaiating  aaowanta  and  data  alamanta/eodaa/eoda  aouieaa.  Than  Hat  any  olhara  (a-O-  X12.9.  X12.S). 

2.  TO  USE  THIS  FORM  TO  REQUEST  A  CHANGE  TO  AN  EXISTINQ  STANDARD,  uaa  a  aaparaiaWtaitinaquaatFefm  to  Hat  an  ehangaa  ter 
ona  tranaaeUon  aot,  ana  tagmant  ana  eonirol  alnieturo.  or  oita  data  atamant  All  aaedona  ntuat  ba  eomplatad.  Attaehmanta  may  ba  uaad 
tor  eonHnuatien  and  ahouW  ba  numbarad. 

3.  TO  USE  THIS  FORM  TO  fCOUEST  A  PROPOSED  NEW  XI2  PROJECT.  oomplataSaciton  A.  Pioaida  a  purpoaa/aoopa  and  daaeriba  any 
naw faaturaa invalvad in SacHon B.  ProHda a daacription ollha buainaaa naad and juatHicatlon tor tha now projact In Saction C/Pait H.  Tha 
Work  Raquaat<i(iHbatorwardadtoanapproprlataX12aubcommittaateranalyaiaandpraparallonotaproiactpropoaal. 

CkclBOnB:  (1)  New  Standard  Supporting  Data  MalntonancB  (use  attachmants) 

(2)  Existino  Standard  Maintananca  Request  (see  Section  D) 

(3)  Request  for  New  X12  Project 

Acranyma/atabraHadona  cannot  baaddadtodwatandarda.  tnduatry  ipaedlc  tamia  muat  ba  ctoatly  aaplalnad.  PtoHda  Appandu  Aeoda 
aourearatorancaa  tor  all  a«tama»ypttbliahad  coda  Hataotad.  lneompiatotormaordtoaaaMhinadaeiiaiaaupporttorS«aehanearaquaaiad 
will  ba  ratumad  to  tha  aubminar. 

A.  SUBMITTER  INFbRMATiON 

Submitter:  Name 

Company  _ 

Address  _ 

Address/ZIP  _ 

Phone  _ 


Indicate  the  Xi2  subcommRtee  or  task  group  whose  position  is  represented  here. 

I  declare  that  this  represents  the  oflldal  position  of  X12  WORK  GROUP: _ 

established  at  the  meeting  datsd _ . 

B.  PROPOSED  WORK:  List  the  specific  changes  to  the  standards  being  requested.  Give  the  names  and 
associated  identifiers  of  the  standards,  segments,  data  elements  and  codes  affected. 
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C.  REASON  FOR  CHANGE: 

Part  I:  List  the  version/reiease  of  the  standard  you  are  using  or  using  as  a  reference.  Name  the  tranaactlon  set 
that  is  being/will  be  used  that  dictates  the  requested  changed.  List  affected  segments  and  data  elemerrts,  or 
other  standaids.  Provide  only  reference  numbers/IOs. 

Reference  Source  Version  2/Release _ 

Transaction  Sot  Used  _ 

Segment  Affected  _ 

Data  Element  Affected _ 

Other  Standard _ 

Part  II:  Explain  why  you  need  the  proposed  change.  Provide  a  complete  scenario  that  tells  what  the  business 
function,  operation,  or  problem  is  that  wPI  be  satisfied  by  a  change  to  the  standard.  The  X12J  Technical 
Assessment  Subcommittee  requires  enough  information  in  this  Part  II  to  be  able  to  propose  an  alternate  solution  if 
necessary. 


D.  RAMIFICATIONS:  If  you  circled  (2)  on  Page  1,  complete  this  section.  To  ensure  that  all  ramificatiorts  of  your 
proposed  change  are  recorded  and  that  your  request  is  complete,  circle  below  all  sections  of  the  standards 
affected  by  the  proposed  change. 


TRANSACTION  SET 

Name 

Sagmant  Petition 
Loop  Rapaat 
Dalate  Sagmant 

Purpota/Soopa 
Raguira.  Oat. 
Loop  Structura 

TaMa  Nota/Commam 
Max.  Uta 

Add  Sagmant 

SEGMENT 

Idantifiaf 

Add  06 

Raguira.  Oat. 
Conwnant 

Nama  Dafinitien 

Oalaia  OEPoaition  in  Sagmant 

Syntax  Nota  Samantie  Nota 

DATA  ELEMENT 

Nwna 

Mn/Max 

Oatcription 

Typa 

CODE 

Add  eeda 

Oalata  Coda 

Ravita  Coda 

OTHER  (e.g.,  X12.5,  X12.6): 

ERRORS  NOTED  IN  THE  STANDARD  (Give  page  no.  and  other  identification); 
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PP  No. _ 

(S«crttiriat  Only) 


A$C  X12 

NEW  PROJECT  PROPOSAL  FORM 

PROCEDURE:  Only  XI 2  subcommittees  may  use  this  form  to  register  new  development  activities  as  X12  project 
proposals  (PPs).  Cimplete  aU  pages.  PPs  approved  by  the  X12  Procedures  Review  Board  will  be  registered  arxl 
assigned  a  PP  number  by  OISA,  and  a  Transmittal  Form  will  be  issued. 

Date  and  complete  the  form  below.  Type  or  print  legibly  In  black  ink  and  number  all  attachment  pages 
consecutively.  Submit  to  DISA  prior  to  an  ASC  X12  meeting,  or  to  X12J  Technical  Assessment  Subcommittee 
during  the  subcommittee's  agenda  period  at  an  ASC  XI 2  meeting. 


Date  Submitted: 

Date  Approved  by  Subcommittee: 

Subcommittee  Name: 

Task  Group  Name/No.: 

Joint  Development  Subcommittee  (H  any): 

Circle  one:  (a)  Transaction  Set  (b)  Guideline  (c)  Other 

Project  Working  THIe: 


Official  Deiegate(s)  for  Thia  Project  To  Be  Named  on  Transmittal  Form: 
Name _ Name _ 


Company _ ^Company 

Address _ ^Address 


Address/ZIP _ ^Address/ZiP 

Telephone _ Telephone  _ 
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A.  PURPOSE  AND  SCOPE  FOR  THE  PROPOSED  WORK:  Provide  a  wali-defirwd  purpose/scope  for  the 
proposed  work.  See  XI 2  Design  RUes  and  Guidelines  for  requirements. 


B.  BACKGROUND:  Provide  detals  that  wll  be  helpful  in  reviewing  the  proposal.  Who  are  the  expected  users? 
How  will  the  standard  be  used?  What  business  functlon(s)  does  R  serve?,  if  the  proposed  standard  overtaps  the 
functionality  of  an  existing  standard  or  one  in  development,  provide  justification.  If  the  proposal  is  not  for  a  new 
standard  or  guideline,  describe  the  project  In  detal.  (Use  attachments  tf  necessary.) 


C.  OTHER  STANDARDS  INVOLVED:  if  applicable,  identify  any  other  business  information  standards  that  are 
simaar/reiated  to  the  proposal,  and  name  standards  developers  (e.g.,  ANSI  AccredRed  Standards  CommRtees) 
whose  activRies  may  be  Invoivad  or  affected. 


D.  EXPECTED  CONTENT/GENERAL  DESCRIPTION:  (OPTIONAL)  SubmRter  may  attach  a  prelimirtary  draft  of 
the  proposed  standard  or  other  supporting  documentation.  Discuss  new  segments,  data  elements,  control 
structures,  and  changes  to  X12.S  or  X12.6  that  are  required  or  anticipated.  (Use  attachments.) 
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FORM  FOR  NEW  OR  REVISED 
APPENDIX  A  CODE  SOURCE  REFERENCE 

INSTRUCTIONS:  Complete  this  form  whenever  a  new  data  element  or  data  element  code  is  requested  to  be 
added  which  references  a  code  list  published  by  an  external  (non-Xi2)  organization.  Use  one  form  for  each  new 
reference.  This  form  may  be  used  to  revise  current  references;  fill  out  the  appropriate  areas  below. 


CIRCLE  ONE,  COMPLETE  AS  APPROPRIATE: 

(1)  NEW  REFERENCE 

(2)  REVISED  REFERENCE,  Current  referertce  number/name 


REFERENCE  TITLE:  If  there  is  only  one  source  for  codes  for  the  data  elemenL  the  title  should  be  the  same  as  the 
data  element  name.  If  there  are  multiple  codes  referencing  external  code  sources  for  the  same  date  elemenL  tMe 
should  approximate  the  code  definitkm. 

REFERENCE  TITLE: 


DATA  ELEMENTS  USED  IN:  Give  the  data  element  reference  number  and  name  which  directs  the  user  to  this 
Appendix  A  code  source  reference.  Give  the  code  ID  (if  assigned)  if  this  is  for  a  specific  code  of  the  data  eiement 

USED  IN:  DE  No.  .  Code  ID 

SOURCE:  Provide  the  name  of  the  publication  which  contains  the  codes  referenced. 

PUBUSHED  IN; 

AVAILABLE  FROM:  Give  the  publisher,  or  other  contacL  from  whom  the  user  can  obtain  the  document 

Name/Attn  of 
Company 

Address _ _ 

Address  _ _ _ 

Address/ZIP  _ _ _ 

ABSTRACT:  Briefly  describe  the  publication,  its  purpose,  and  Indicate  what  codes  it  contaifo! 

ABSTRACT: 


e.o.a 
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DOCUMENT  PREPARATION  FOR 
INTERPRETATIONS.  GUIDELINES  AND  CONTROL  STANDARDS 

These  instructions  are  provided  to  assist  developers  of  interpretations,  guideiines  and  control  structure  which  are 
not  transaction  sets  (for  transaction  sets  use  the  New  Transaction  Set  Development  Form). 

GENERAL:  OISA  provides  tMe  page  and  front  matter  for  publications  and  copyedits  the  document  according  to 
DISA  house  style. 

REVISIONS:  If  the  document  Is  a  revision  of  a  previously  published  interpretation,  guideline  or  standard,  provide  a 
summary  of  the  changes  to  the  original  that  are  contained  in  the  document 

I  INTERPRETATIONS 

A  formal  Interpretation  of  an  Standard  Is  considered  part  of  the  body  of  standards  when  It  is  approved  for 
publication.  The  Interpretation  draft  should  state  the  issue  presented  by  the  requestor,  state  the  proposed 
interpretation,  and  show  as  attachments  any  Work  Requests  that  may  be  necessary  to  effect  the  interpretation 
within  the  subject  standard.  The  draft  Interpretation  is  processed  tike  any  other  subcommittee  documem 

II  GUIDEUNES 

For  publication  purposes,  guidelines  are  treated  like  a  journal  article.  Basic  requirements  are  given  below. 

ABSTRACT:  This  is  a  precise  summary  of  the  Purpose/Scope  (see  below),  and  may  be  identical  to  It  If  that  Is  brief 
(two  paragraphs);  otherwise  summarize  the  purpose/scope.  It  should  contain  erwugh  information  about  the 
document  to  enable  a  reader  determine  what  the  guideline  is  intended  to  accomplish  wtthin  an  EDI  envirotwnent. 

PURPOSE  AND  SCOPE:  This  statement  must  Indicate  purpose  of  the  guideline,  e.g.,  the  business  function  or 
operation  addressed.  Scope  and  any  specific  limitations  of  scope  should  be  defined. 

BODY  OF  TEXT:  This  may  be  a  number  of  subsections  logicaiiy  organized.  Provide  sections  for  foreword, 
introduction,  definition  of  terms  and  concepts,  references  and  related  standards,  methodology,  specifications, 
requirements,  discussion,  and  conclusions,  as  appropriate  to  the  subject 

ART  AND  GRAPHICS:  Graphics  or  artwork  necessary  to  llustrate  the  document  are  encouraged.  Provide 
camera-ready  copy  if  these  are  not  already  prepared  and  delivered  on  a  WP  diskette  to  DISA. 

FOREWORD,  FOOTNOTES.  APPENDICES:  These  may  be  used  for  purposes  of  darity,  llustration,  or  general 
information,  not  as  'part  of  the  guideline.*  A  statement  indicating  the  material  is  for  information  purposes  only  and 
not  part  of  the  guideline  shall  appear  at  the  beginning  of  a  foreword  or  appervlix. 

III  CONTROL  STRUCTURES  AND  OTHER  STANDARDS 

For  publication  purposes,  these  documents  are  treated  like  guideiines  (see  Section  II  above).  The  requirements  are 
the  same,  with  ^  addition  of  the  following: 

NEW  SEGMENTS  AND  DATA  ELEMENTS:  These  may  be  defined  within  the  text;  however,  since  they  represent 
changes  to  X12.22  and  X12.3.  they  should  be  specified  on  a  Work  Request  Form  attached  to  the  draft. 

REUTED  X12TM  STANDARDS  AND  OTHER  REFERENCES:  These  shall  be  identried  In  a  section  within  the  text. 
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FORMAT;  *71)13  Draft  Standard  for  Trial  Ua*  contain*  the  format  and  establisKes  the  data  coittents  of  the 

_ Transaction  Set  ( _ )  for  use  within  the  context  of  an  Electronic  Data  Interchange  (EDI) 

environment.  The  transaction  set  (can  be  used  to...)* 


C.  PURPOSE  AND  SCOPE  This  statament  must  indicate  the  full  range  of  capaUities  of  the  transaction  set,  and 
)who  the  senders/receivers  are.  Explain  the  business  function  or  operation  that  is  addressed.  FqI1owASCX12 
Design  Rules  and  Guidelines  and  use  this  format: 

FORMAT:  This  standard  provides  the  format  and  establishes  the  data  contents  of  the  Transaction 

Set  within  the  context  of  an  Bectronic  Data  Interchange  (EDI)  environment  This  transaction  set  (can  be  used  to...)* 


0.  TRANSACTION  SET  TABLE(S)  For  each  table  provide  the  following  Information.  FORMAT: 

TABLE X 


POSITION  SEGMENT  REQ.  MAX. 

fiSj - in _ TITLE _ DES.  USE. 

010  ST  Transaction  S«t  Hsadsr  M  i 

020  BB  Beginning  Segment  For  M  1 

etc. 


LOOP  REPEAT  NOTE 

COUNT _ BEL. 

Note  1 
Comment  l 


Notei;  This  Is  a  note.  NOTES  are  part  of  the  standard  (numbered). 

CommentA:  This  is  a  comment  COMMENTS  are  not  part  of  the  standard  (letterad). 


E.  APPENDIX  EXAMPLES  Examples  are  used  to  test  the  merit  of  the  proposed  transaction  and  to  explain  E  to 
users.  At  least  one  example  Is  mandatory.  No  recognizable  proper  names  may  be  used  In  any  aixample. 

nCUREl:  (Optional)  Use  a  sample  paper  document  using  mock  data.  If  used,  data  must  be  accurately  mapped 
to  Figure  2.  Original  graphics  must  be  attached  (8-1  /2xli*)  so  they  can  be  copied. 

FIGURE  2  (or  EXAMPLE):  TMe  the  figure  and  provida  a  Business  Scenario  to  explain  to  the  reader  what  Is  going 
on  in  the  example.  Addthenote:  Tn  this  example  the  asterisk  (*)  represents  the  data  elemeni  separator  and  the 
N/L  characters  represent  the  segment  temninator.*  Present  EDI  transmission  data  and  Its  meaning  in  two  columns, 
side-by-side.  S  or  SZ  codes  ars  discouraged,  since  their  usefulness  in  an  explanatory  example  is  m.  FORMAT: 

BUSINESS  SCENARIO:  In  this  transaction  set  the  sender  is  XYZ  Ratal  Center  and  the  recelvar  Is  their  supplier. 
Fantastic  Products  Manufacturing,  lnc....stc 

EOLTPANSMISSIONPATA _ fTRANSACnON  SET  PURPOSE)  DATA 

ST*8XX*0005  N/L  Begin  Transaction  Set  8XX;  Control 

No.  0005 

BB*01*79800*  N/L  Original  Transmission;  Ref.  No. 

79800 

etc. 
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R*v  5/10/90 

DM  Number _ 

(Secretariat  Only) 

Document  No. _ 

(Developer  Obtains  from  DISA) 


ASC  X12 

NEW  TRANSACTION  SET  DEVELOPMENT  FORM 


INSTRUCTIONS:  Use  this  form  to  submit  a  draft  transaction  set  for  review  by  XI 2J  Technical  Assessment  until  it  is 
te)(t  processed  by  DISA.  Use  a  new  Transaction  Set  Development  Form  whenever  revisions  are  proposed  and  a 
text  file  has  not  yet  been  prepared  by  DISA. 

ATTACHMENTS:  Attach  all  pages;  use  this  form  as  the  first.  Follow  these  Instructions  for  preparing  materials. 

The  submitter  must  obtain  a  document  number  assignment  from  DISA.  Post  It  to  this  form  (above). 

Attach  a  Ust  of  Revisions  if  the  draft  was  previously  reviewed  by  XI 2J  or  if  this  is  a  revised/redesigned 
transaction  set  standard  requiring  XI 2  ballot 

Use  ONE  Work  Request  Form  to  list  all  supporting  data  maintenance  for  the  transaction  set  and  attach  It 
to  this  form.  Propose  new  or  revised  codes  for  DE  143  and  DE  479  at  a  minimum.  If  required. 

A  Transmittal  Form  must  accompany  this  document  when  It  Is  submitted  to  DISA  for  distribution. 

Use  the  most  recent  XI 2^*^  Standards  Development  Workbook  to  check  your  document  for  accuracy. 

A.  SUBMITTER  INFORMATION 

Submitter:  Name  _ 

Company  _ 

Address  _ 

Address/ZIP  _ 

Phone  _ 

Indicate  the  XI 2  subcommittee  or  task  group  whose  position  Is  represented  here. 

I  declare  that  this  represents  the  official  posMon  of  X12  WORK  GROUP: _ 

established  at  the  meeting  dated _ 


B.  ABSTRACT  The  Abstract  Is  registered  with  the  American  National  Standards  Institute.  It  is  a  precise  summary 
of  the  Purpose/Scope  (see  Section  C  below).  It  may  be  Identical  to  the  Purpose/Scope  If  that  is  brief  (two 
paragraphs),  otherwise  summarize  the  purpose/scope.  It  should  contain  enough  information  about  the  standard 
to  enable  a  potential  user  determine  what  equivalent  paper  transaction  It  represents  or  what  the  standard  Is 
Intended  to  do.  Follow  the  format  on  page  two. 
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SAMPLE  TRANSMITTAL  FORM 


initlalizod 

KEY  DATE:  Fobniary  15. 1990 

DELEGATES  NAME 

RESPONSIBLE  SUBCOMMITTEE/TG# 

John  Doe 

ASC  X12Q  XX  Subcommlttee/TG4 

TRANSACTION  SET/GUIDEUNE  TITLE 

X12X(  ABC/XYZ  TRANSACTION  SET  (8XX) 

BALLOT  Document  No. 

Cunent  Document  No. 

Previous  Document  No. 

Project  Proposal  No. 

Associated  WR/DM  No. 

ASCX12Q/9(H)51 
ASC  XI 20/90-004 
PP-999 

DM  012-190 

PROJECT  PROPOSAL 

PP  Reviei»'byXl2J 

PRB  Approves  PP 

(DATE)  2/7/90 
PATE)  2/9/90 

DEVELOPMENT  PHASE:  Project  proposal  approval  through  approval  for  XI 2  vote. 

Document  Submitted  for  DiSA  Text  Processing 

Subcommittee  Approves  Draft  for  Review  by  X12J.  Tech  Assessment 

X12J  Tech  Assessment  Review 

PRB  Approves  Document  for  X12  Vote 

PATE) 

PATE) 

PATE) 

PATE) 

ORIGINAL  BALLOT  DATA  (DISA): 

Ballot  Oosed  Date 

Taliy/Comments  Sent  to  Chair/Delegates 

Tally  Stats  (Number  and  Percera) 

Ballots  Mated  (100%) 

Ballots  R^umed  (  %) 

Approved  C  _%) 

Appw/Convnenl  (  %) 

Disapproved  (  %) 

Abstained  (  %) 

PATE) 

PATE) 
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COMMENT  RESOLUTION  PHASE:  See  Sections  A.  B  and  C.  If  dte  subcommittee  at  any  time  decides  to  rebaUot 
the  document,  PRB  approval  Is  required  and  response  letters  are  not  necessary. 

A.  COMMENT  RESPONSE  LETTERS:  An  Open  Forum  must  be  scheduled  at  the  next  X12  meeting  foliowing  the 
baMot  dosing  date.  All  those  who  commented  receive  a  comment  response  letter  from  the  developing 
subcommittee.  OISA  records  this  process  and  handles  the  maling. 

Open  Forum  Date  (DATE) _ 

Response  Letters  Mated  Out  by  OISA  (DATE) _ 

Rebuttal  Period  (30  days)  Oosae  PATE) _ 


ADJUSTED  BALLOT  DATA  piSA): 

30^ay  Response  Review  CkMed  Date  PATE) 

Tafly/Comrnents  Sent  to  Chalr/Oelegates  (DATE) 

Tally  Stats  (Number  and  Percent) 

_ Ballots  Mated  (100%) 

_ Batots  Returned  ( _ ^%) 

_ Approved  (__%) 

_ Appw/Comment  (  %) 

_ Disapproved  ( _ %) 

_ Abstolned  ( _ ^%) 


B.  SUBSTANTIVE  REVISION:  If  batot  comments  result  in  substantive  revisions  to  the  documerR.  these  are 
reviewed  by  X12J  and  processed  by  DISA  The  revised  documera  Is  submitted  to  X12  voters  for  a  30-day  review 
period.  01^  records  this  process/handles  mating.  Subcommittees  should  conduct  30-day  rsMsws  for  response 
letters/revised  documents  concurranlty. 


Subcommittee  Approval  of  Revisions  PATE) 

X12J  Review  of  Revisions  PATE) 

OISA  Mats  Revised  Document  PATE) 

Subsuntlve  Revision  30-Oay  Review  Ooses  (DATE) 


ADJUSTED  BALLOT  DATA  piSA): 

30-0ay  Substantlvs  Change  Review  Ctosed  Date 
Taly/Comments  Sent  to  Chalr/Oelegates 
Taly  Stats  (Number  and  Parcertt) 

_ Baflou  Mated  (100%) 

_ Batots  Returned  ( _ %) 

_ Approved  ( _ ^%) 

_ Appw/Comment  (___%) 

_ Disapproved  ( _ %) 

_ Abstained  ( _ ^%) 


PATE) 

PATE) 
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C.  CONTINUING  OBJECTIONS.  If  there  are  continuing  disapprovals  after  the  30-day  review  period,  the 
document/disapprovals/responses/continuing  objections  are  mailed  to  XI 2  members  who  originally  cast  a  ballot, 
for  another  30-day  review,  to  give  them  an  opportunity  to  change  their  vote. 

Continuing  Objections  Mailed  to  Chair/Delegate  by  OISA  (DATE) _ 

DISA  MaRs  Documents  (DATE) _ 

30-Day  Review  Closes  (DATE) _ 


FINAL  ADJUSTED  TALLY  (DISA):  Whenever  any  disapprovals  are  withdrawn,  a  letter  to  this  effect  must  be 
received  in  writing  by  DISA 

Rnal  Tally  Results  Sent  to  Chalr/Oelegate  (DATE) _ 

30-Day  Review  Stats  (Adjusted  Tally) 

_ Ballots  MaRed  (100%) 

_ Ballots  Returned  ( _ ^%) 

_ Approved  ( _ ^%) 

_ Appw/Comment  ( _ %) 

_ Disapproved  ( _ %) 

_ Abstained  ( _ ^%) 


PRB  APPROVAL  PHASE:  After  the  comment  resolution  period,  the  subcommittee  votes  to  submit  the  document 
to  the  PRB  for  approval  to  publish. 

Subcommittee  Votes  to  Release  to  PRB  pATE) _ 

PRB  Approves  Publication  PATE) _ 

FOR  DRAFT  STANDARDS  FOR  TRIAL  USE: 

VERSION/RELEASE/SUBRELEASE  ID  CODE  ASSIGNED: _ 
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TRANSMITTAL  FORM  INSTRUCTIONS: 

GENERAL:  This  Transmittal  Forni  is  a  TURNAROUND  DOCUMENT  which  records  the  history/current  status  of  a 
project  document  It  is  used  to  exchange  krformation  between  the  Secretariat  and  the  committees  of  X12. 
Information  Is  cumulativ*  (add  on).  This  form  is  attached  to  the  document  whenever  It  Is  Issued  for  distribution  (K  is 
mandatory  for  submitting  documents  to  DISA,  X12J  Technical  Assessntent  and  the  PRB).  Document  control 
numbers  are  stil  required  on  each  documenL  and  new  numbers  are  required  whenever  K  is  revised. 

KEY  DATE:  This  Is  used  to  identify  the  latest  version  of  the  document  (date  associated  with  the  current  transmittal 
form  update). 

DELEGATE:  Each  subcommittee  designates  an  Individual  (delegate)  from  the  group  responsible  for  the  project 
The  Secretariat  must  be  Informed  tf  the  delegate  chartges. 

INITIATION:  Primary  data  Is  recorded  by  DISA  on  the  Initialized  form  after  the  project  proposal  Is  approved  by  the 
PRB.  The  subcommittee  chair  and  delegata(s)  racelve  die  Intiallzad  Transmittal  Form  from  DISA:  thereafter,  they 
are  responsible  for  recording  the  appropriate  subcommittae  approval  dates.  The  chair/delegate  wH  racelva  a  copy 
of  the  updated  transmiiial  form  whenever  It  Is  revised  by  DISA. 

UPDATING:  At  each  appropriata  step,  DISA  wll  POST  fresh  data  to  the  form,  ADD  the  next  appropriate  blanks  to 
the  form,  arxj  SEND  R  to  the  subcommittee  chair/delegate  at  each  status  change.  The  delegate  must  POST  the 
form  with  fresh  data  at  each  status  change  for  which  the  subcommittee  is  responsible  and  SEND  It  with  the 
appropriate  document  to  the  Secretariat. 


910430 


9.0.16 


DEPARTMENT  Of  OffDlSE 
IMPLEMENTATION  QUE>EUNa 


ASC  X12  BALLOT  COMMENT 
RESPONSE  LETTER  FORMAT 


GENERAL  INPORMATION 


AFTER  AN  Xia  BALLOT,  1NE  RESPONSIBLE  SUBOOMIHTTEE  (OR  ITS  OESIONATEO  TASK  GROUP)  MUST  mpond  in  mWng  to  M 
Gioppravwl  volof.  Oisanizaton  4  PreeaduiM  nwnual  (0PM)  oMm  flwi  you  wo  net  raqjind  to  ratpond  to  tiOM  momboti  who 

■OptwodwitooommonLbutiypcolyolcommonMfoofOtoopowdidto.  Tho  0PM  ototoo  thoi  al  cowmont  iwtponooo  muot  bo  eoui'dtootod 
witti  too  Subeommiitoo  Chair. 


'TharoaroiwotoaponMloatotormattlromMMehtoehooao;  opanortoloaorwhKhwSboaonitoal 
roaponsotooachoommomor.  SoointtoidionabolowandtooMndnwnia. 


cowintontoia,  and  a  IndviAialrort 


OPTION  1:  GENERIC  LETTER  (MASTER  LETTER)  TO  AaCOHMBITORS 

Youmay  proparaonolaiartoboaanitoaloofflmantort.  EMryoommantneowodnwatborapraduoadlnyeurloSBr.  Foroadieommant 
iatod.naino  too  comwantof  (XI 8  wambar  company  nawa)  and  too  votoioewdod  ter  toow.  LM  yaw  loaponao  to  too  oommant  Ifyou 
ehooao  toia  option,  you  may  group  too  eommania  which  amaMlar  and  raapond  to  toomaa  a  greup.  Etoty  mambor  itat  daapptotad  mutt  bo 
foapondadto. 

OPTION2:  MOIVIOUAL  LETTER  TO  EACH  COMHENTOR 

Youmay  pmporoono  tetter  tor  aaoheommontor.  H  you  chooaatoiaopdon.  you  naod  not  lopaat  too  original  oommootproMdad  on  toa  ballot 
Folowtoouaualbuainoaalaitoraiyteandtoogonaralinatoiedanabotow.  Eaoiy  mambor  toatdbapproMdmuat  bo  raapondad  to. 


saTRucnoNs 

STEPi:  Plan  to  print  too  HratpagoolyowlattHta)  on  ASC  Xiaioaaihoad.  ff  you  dbni  haw  teoarhaod.  you  oan  obtain  aoma  team  too 
SMTMinBt  Of  rmrmOjoo  ttio  BOMlo  ottMhod.  You  mov  mM  um  aononoi  oofoomo  or  blonk  lottortuMl  lor  vour  flomnionl  imoomo  loBMf o) 

w^w  ^warv^pmp  araaaapaw  w^Ob  a  aiptow  aaopa  aaw  iwitoawaawaPb  aww  pwparmw^  aw  awwpr^a  ^wwra  wpvari  waa  vawsa  aaawaraaww  w  aai^^SWia  avas^m  Ltof  • 

STEPS:  CaltoaSoerotariattoradooumontoonoolnumbor.  Thia  numbormuat  appear  in  too  upper  right  oomor  of  too  flrat  papa  ol  too  tebar. 
ff  you  wuno  on  wownoiwuoo  soif  w  open  ooffWiOnWf,  MiO  oocuffioni  coiiwOi  nuwoor  ooii9nOO  lOf  wo  imIa  Mtwf  WM  00  spBowoo  By  on  A 
(o.g.,  ASC  X12P/rO9A0-ta0A),  too  aaoond  by  a  *6*  (a.g.,  ASC  X12F/TGMO-1SOB).  oto. 

STEPS:  Chooaa your tesartennat option (aaaQonoralIntormoionabow). 

STEP  4:  Prapara  too  tetter  teWowing  too  outlina.batewuaing  a  typicaibuainaaa  tesartennat 

a  Provida  a  contact  namo(iandara)  In  too  uppar  right  oomor  boa  of  too  tettorhaad'.includi  phono  numbar. 

b.  Print  too  document  contol  numbar  under  too  teBorhaad  boa. 

c.  Print  too  date  under  too  doeumonl  consol  number. 

d.  AddraaatoalasartotooinGuldual.orteraganartcteBarlncludaanadGainelnaandiUb)act>ia. 
a.  Inctuda  an  Insoduetory  paragraph  00  too  taaua  la  proparilfldamWod  to  too  addiaaioa. 

f.  You  may  wiah  to  raeap  too  baltettoly  (bom  yew  TranamHtol  Form)  ter  too  tetermadon  of  too  reader. 

STEP4:  FotwardtootoaaratotoeSaetatBriaLAitenSenSaeratariaiSoivieoB.witoaeewrlaBwraquoaiingdtetibutionoltooraapenas 
teaor(t)yeuhawpraparad.  Whan  too  tesars  haw  boon  Gitributad.  too  projoadategato  and  auboemmbtoo  char  wiraoatw  an  updated 
Tranamioai  Form  which  haa  too  maling  date  and  SGday  raviaw  ported  eteaing  data  posted. 


ASaohmanti: 


X12  Laasrhaad  Sampte 
Sampte  Master  Roapenao  Latter 
Sampio  Indvidual  Loser 
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ASC  XI 2-ELECTRONIC  DATA  INTERCHANGE  [EDI] 


Tim  Jonesey 
(999)  999-9999 


Accmftted  Standards  Committee 
operating  under  the  procedures  of  the 
American  National  Standards  insutute 


Dan  Smithey 
(999)999-9999 


Document  No 

ASC  X12C/TG20/90-999 
June  25, 1990 


TO:  X12  Members  Who  Commented  on  Modifications  to 

X12jac  Control  Structures 

RE:  Response  to  Comments  on  December  Ballot 

DMs  205289, 215289. 317289 


Thank  you  for  your  comments.  This  ballot  involved  modifications  to  X12jk  Of  the  327  ballots  mailed,  153  ballots  were 
returned.  Of  these,  81  approved,  15  approved  with  comment,  20  disapproved  with  enmm^at  and  37 

In  general,  the  vote  responses  were  in  favor  of  the  modifications.  The  majority  of  the  tnmnieau  focused  on  the  impart 
of  these  modifications  on  the  presentation  of  information  in  the  X12.22  S^ent  Directoiy.  The  proposed 
and  ^  resulting  presentation  in  the  segment  directory  have  been  reworked  in  response  to  these  comments.  A  revised 
modification  to  X12ja  was  reviewed  by  Technical  Assessment  at  the  June  ASC  X12  meeting.  to  the 

documrat  have  been  made  which  reflek  responses  to  the  cmnmentt  from  this  ballot,  and  a  revised  copy  of  X12ja  is 
being  distributed  to  all  who  voted  on  this  issue,  for  30-day  review  of  revisions. 

Specific  responses  to  comments  follow. 


COMMENT:  Automobile  Corporation 

‘Add  the  following  note  to  Paragraph  33:  NOTE:  Communication  protocol  charaaers  should  be  rr^lwdrd  from  the 
charaaer  set* 

RESPONSE: 

The  cover  letter  seat  out  with  the  voting  package  explained  that  the  intent  was  to  obtain  rops^nsui  on  the  proposed 
modifications  to  X12.XX,  X12jk  is  a  difficult  standard  to  amend.  We  request  that  ballot  responses  be  considered  on  the 
merito  of  the  recommended  modifications  and  not  on  the  standard  as  a  whole.  Your  comment  was  outside  the  scope  of 
the  requested  modifications. 
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COMMENT:  Airaaft  Engine  Corporation 

*Some  consideration  for  Abstract  Syntax  Notation  One  (ASN.l)  should  be  allowed. 

1.  ASN.l  is  capable  of  all  of  the  necessary  inter-relations  needed  by  X12  transactions. 

1  ASN.l  requires  less  characters  to  define  the  same  information. 

3.  ASN.l  is  the  encoding  scheme  used  by  most  OSI  work.* 

RESPONSE: 

The  recommendation  to  consider  usage  of  ASN.l  encoding  reaches  far  beyond  the  scope  of  the  modifications  requested 
in  this  ballot.  Activities  such  as  this  are  best  submitted  as  separate  work  requests. 

COMMENT:  Some  Software  Inc. 

’Conditionality  of  data  elements  should  be  left  to  the  discretion  of  implementation  guidelines  and  agreements.  There  is 
much  discussion  at  times  as  far  as  whether  certain  data  elemenu  should  be  mandatory  or  not;  many  application  systems 
are  incapable  of  providing  certain  ‘mandatory  information  and,  as  such,  filler-type  data  must  be  inserteiL* 

RESPONSE: 

The  issue  of  data  element  conditionality  as  a  whole  is  a  much  broader  sulqect  than  was  mtended  to  be  addressed  within 
the  scope  of  this  ballot.  ‘This  ballot  was  intended  to  provide  a  means  for  consistent  documenution  and  application  of 
already  existing  conditional  structures.  If  the  commentor  believes  that  the  conditional  structure  should  lie  removed  from 
the  standard,  the  task  group  recommends  that  this  be  submitted  as  a  separate  work  request. 

Ecc . 


9.0.18 


910430 


DiPARTMOIT  OF  OffENM 
iMFLBMENTATION  OUDaMit 


ASC  X1 2-ELECTRONIC  DATA  INTERCHANGE  [EDI] 

Accredited  Standards  Committee 

Joe  Somebody 

operating  under  the  procedures  of  the 

Chair  TG19,X12C 

American  National  Standards  institute 

(999)  999-9999 

Documenc  No 


ASC  X12C/rG8/9a-998A 
August  10, 1990 

Ms.  Jane  Doe 
American  Bank 
One  Central  Plaza 
Middle  America,  MO  99999 

R£:  Response  to  Ballot  Comments  on 
ASC  X12  Model  Guideline 

Dear  Ms.  Doe: 

Subcommittee  X12C  has  empowered  its  Task  Group  19  to  provide  responses  to  the  comments  on  this  ballot  The 
members  of  TG19  wish  to  th^  all  X12  members  «iio  took  the  time  ^  effort  to  vote  on  this  guideline.  We 
especially  thank  each  individual  who  provided  comments,  whether  in  approval  or  disapproval  of  the  guideline.  We 
recognize  and  appreciate  your  careful  review  of  this  document 

Our  response  is  keyed  to  the  numbered  items  in  the  comments  attadied  to  your  ballot 

RESPONSE 

L  We  agree  with  your  comment  In  Section  4.Z2,  we  have  replaced  *we  utilize  rules  >.*  with  ‘rules ...  are  utilized*. 

2.  The  confusion  between  Section  423  and  Section  62  only  exists  because  of  the  example  we  chose  in  the  first 
section.  This  is  a  hypothetical  example,  of  a  simplified  mo^  Headen  and  trailers  can  be  placed  on  the  content  at 
ALL  levels,  and  do  not  necessarily  correspond  to  ASC  X12  headen  and  trailers. 

3.  We  agree  with  your  comment  Section  62  has  been  changed  so  that  *lhe  establishment  of  _.*  was  added  to  items 
1  and4. 
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INTRODUCTION 


Gon0ral  information 
on  ANSI.  XI 2  and 
DISA  is  givon. 


ANSI 

The  American  NaUonal  Standards  Institute  (ANSI)  was  founded  in  1918  as  the 
rtational  coordinator  of  the  voluntary  standards  system  for  the  United  States. 

The  system  meets  national  standards  needs  by  marshaling  the  competence  and 
cooperation  of  commerce  and  industry,  standards  developing  organizations,  and 
public  and  consumer  interests.  ANSI  coordinates  the  voluntary  development  of 
national  consensus  standards,  approves  standards  as  American  National 
Standards,  and  serves  as  a  clearinghouse  and  information  center  for  American 
National  Standards  and  interrtational  standards. 

ANSI  UseM  does  not  develop  standards.  It  approves  a  standard  or)ly  when  it  has 
verified  evidence  presented  by  a  standards  developer  that  those  affected  by  the 
standard  have  reached  substantial  agreement  (consensus)  on  its  provisions. 
ANSI-approved  standards,  including  XI 2  EDI  standards,  currently  number  over 
8,500.  They  provide  requirements,  terminology,  tests  for  everything 
imaginable... beveled  washers...safe  use  of  lasers... kitchen  cabinets...computer 
software...building  accessibility  for  handicapped  people.  They  have  one  main 
characteristic  in  common:  they  can  be  used  with  confidence  because,  in  each 
case,  ANSI  has  verified  evidence  that  those  directly  affected  reached  substantial 
agreement— consensus— on  the  standards'  provisions. 

Consensus  is  the  heart  of  the  ANSI  system.  Democracy  prevails.  ANSI  provides 
on  open  forum  for  all  concerned  interests  to  idenlify  standards  needs,  to  plan  to 
meet  those  needs,  and  to  ^ree  on  standards. 


ASCX12 

In  1979  ANSI  chartered  the  Accredited  Standards  Committee  (ASC)  X12  to 
develop  uniform  standards  for  inter-industry  electronic  interchange  of  business 
trar»actions. 

The  main  objective  of  the  ASC  X12  Committee  is  to  develop  standards  to 
facilitate  electronic  interchange  relating  to  such  business  transactions  as  order 
placement  and  processing,  shipping  and  receiving  infonnatiqn,  invoicing,  and 
payment  and  cash  application  data. 

In  ASC  X12,  various  subcommittees  develop  new  standards  that  become 
recommendations  for  the  full  XI 2  membership.  Proposed  startdards  must  be 
approved  through  the  consensus  process  before  a  standard  (or  any  change  to  a 
standard)  is  approved  and  registered  with  ANSI. 

asA 

The  Data  Interchange  Standards  Association,  Inc.  (DISA)  was  formed  in  1987  to 
be  the  Secretariat  and  administrative  arm  of  ASC  X12.  DISA  is  a  not-for-profit 
corporation,  and  Ks  staff  manages  XI 2  membership,  balloting,  international 
programs,  standards  maimenanoe,  publications,  the  annual  conference  and 
exhbit,  X12  meetings,  communications  with  ANSI  on  behalf  of  ASC  X12,  and 
other  administrative  duties  required  to  support  the  Xi  2  Committee. 
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ASC  X12  ORGANIZA  TION 


This  section 
discussss  th»  ASC 
X12  organization. 


ASCXl2Mtmb0tahlp 

X12  is  an  Aocredited  Standards  Commitlee  operating  under  the  procedures  of 
the  American  National  Standards  Institute.  Its  membership  is  open  to  any 
individual,  company  or  organiz^ion  which  may  be  directly  and  materially  affected 
by  XI 2  activities.  Annual  dues  payment  is  required  for  membership  (see  Section 
VII  for  a  Membership  Form). 


Membership  has  grown  dramatically 
(from  fewer  than  1 00  to  over  300  in  a 
two-year  period)  and  stands  at  over 
460  today.  Benefits  include  an 
opportunity  to  vote  on  every  issue 
before  the  X12  Committee,  price 
discounts  on  standards  publications, 
reduced  attendence  fees  at  the 
annual  conference,  free  X12  meeting 
registration,  and  continual 
Momnation  updates  on  committee 
activit'ies  and  standards. 


SscntartMt 

The  Data  Interchange  Standards 
Association,  Inc.  (DISA)  is  a 
not-for-profit  corporation  which  was 
formed  in  1987  to  be  the  ASC  X12 
Secretariat  and  administrative  arm  of 
the  committee.  DISA  also  serves  as 
the  Secretariat  for  the  North 
American  EDIFACT  Board  (NAEB), 
whose  activities  are  aimed  primarily 
at  the  developmeni  and  maintenance 
of  the  international  EDI  standards. 


ASC  X12  Chair  and  Vlea  Chair 

The  ASC  X12  Chair  and  Vice  Chair 
are  elected  by  majority  vote  of  the 
XI 2  members  to  serve  a  two-year 
term  of  office.  Elected  at  the 
October,  1989  meeting  are  the 
current  Chair,  Ken  Hutcheson  (Du  Pont  Company),  and  Vice-Chair,  Jim  Sykes 
(Levi  Strauss  &  Company).  Their  terms  of  office  expire  in  October  1991 . 


Staaring  Committaa 

The  ASC  XI 2  Steering  Committee  develops  recommendations  for  the 
administration  of  X12  in  close  coordination  with  the  Seaetariat.  The  Steering 
Committee  is  composed  of  the  X12  Committee  Chair,  Vice  Chair,  Subcommittee 
Chairs,  and  past  officers.  Non-voting  members  include  a  Secretariat 
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representative,  Steering  Commitiee  Task  Group  Chairs  and  a  recording 
secretary. 

The  Steering  Committee  has  several  standing  task  groups: 

•  Annual  Conference  Task  Group  coordinates  the  XI 2/DISA  Conference  and 
Exhibit. 

•  Legal  and  Business  Control  Issues  Task  Group  provides  information  and  per- 
fomrs  studies  on  legal  issues  surrounding  the  use  of  EDI. 

•  VersiorvRelease  Task  Group  is  responsible  for  the  form  and  forniat  of  ASC 
X12  Draft  Standards  tor  Triad  Use.  and  X12  American  National  Standards. 

•  Planning  Task  Group  is  responstoie  tor  long-tenn  and  short-term  planning  for 
ASC  XI 2  in  the  areas  of  technical  issues,  public  relations  and  finance. 

•  X12/EDIFACT  Alignment  Task  Group  is  charged  with  formulating  recommen¬ 
dations  for  achieving  one  set  of  global  EDI  standards. 

Pneodun$Rmfhw  Board 

The  Procedures  Review  Board  has  primary  responsibility  to  ensure  that  due 
process  is  followed  before  approval  of  new  project  proposals,  releasa  of 
documents  for  X1 2  Committee  ballot,  and  publication  of  standards. 

North  Amartean  Eor  ACT  Board 

The  North  American  EDIFACT  Board  (NAEB)  is  an  X12  Committee  Standing 
TaskGroup.  This  group  serves  as  the  tonjm  tor  developmert  of  the  North 
American  position  on  international  EDI  message  standards  and  relatad  issues. 
EDIFACT  standards  developmerx,  maintenance  and  technical  assessment  in 
North  America  occur  within  the  national  standards  bodies  of  the  United  States 
(ASC  X12)  and  Canada  (Standards  Council  of  Canada  Joint  Technical 
Committee  on  EDI). 

ASGX12  Stdteotnmmaaa 

The  X12  Commlltee  is  the  decision-making  body  responstole  tor  developing  the 
evidence  of  consensus  necessary  tor  approval  of  American  National  Standards. 
Suboommitteee  are  assigned  resfxmsiiility  for  specific  standards  developmert 
and  standards  maintenance  activities,  but  their  work  must  be  ratified  by  the 
membership  of  ASC  XI 2. 
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THE  ASC  X12  STANDARDS  PROCESS 


Th0  following  is  a 

pf»cisofASCX12 

standards 

davalopmant  and 

maintananco 

procadures. 


Organlxmion  S  Ptoetdunt  Manual 

The  ASC  XI 2  Organization  &  Procedures  Manual  (0PM)  is  the  official  source  for 
information  on  standards  processing  requirements.  The  following  material  has 
been  excerpted  from  that  document  to  give  you  an  idea  of  the  process,  and  as  a 
reference  source. 


P/ocaaaIng  Dratt  Standarda  for  Trial  Usa 
General 

To  maintain  its  acaedited  committee  status, 
ASC  XI 2  must  follow  these  procedures  to 
ensure  compliance  with  the  ANSI 
Procedures  for  the  Development  and 
Coordination  of  American  National 
Standards. 

VOTING.  These  voting  procedures  apply  to 
X12  and  subcommittee  votes.  For  a  letter 
ballot  the  voting  positions  are:  (1)  approve, 
(2)  approve  with  comment,  (3)  disapprove 
with  reasons,  (4)  abstain.  A  member  not 
voting  is  designating  no  interest  in  the 
matter  subject  to  the  vote.  The  letter  ballot 
voting  period  shall  be  45  days  from  the 
mailing  date  unless  otherwise  designated  in 
these  procedures.  Voting  at  a  meeting  may 
occur  if  the  technical  comments  can  be 
addressed  through  discussion  or 
amendments. 

For  a  letter  ballot,  20%  of  the  baUots  mailed, 
including  abstentions,  must  be  returned  or 
the  issue  is  unresolved.  Unless  othenwise 
specified,  a  favorable  vote  by  X12  or  any 
subcommittee  means  two-thirds  approval 
vote  by  the  voting  members  present  at  a 
meeting  or  by  two-tNrds  approval  of  the 
ballots  returned  tor  a  letter  ballot;  no  interest 
and  abstentions  are  not  counted. 

Planning  Phase 

The  first  phase  covers  the  examination  of  a 
proposal  that  X1 2  undertake  development  of 
a  new  standard  or  revision  of  a  published 
standard. 

WORK  REQUEST.  A  work  request  may  be 
developed  by  any  individual  or  organization 
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whether  or  not  associated  with  ASC  X12.  The  work  request  is  sent  to  the 
Secretariat  for  precessing.  This  work  request  is  then  reviewed  by  the  Technical 
Assessment  Subcommittee  (TAS)  which  may  refer  the  work  request  to  one  or 
more  developing  subcommittees.  This  work  request  may  result  in  other  action, 
including  maintenance  to  an  existing  standard. 

PROJECT  PROPOSAL.  The  developing  subcommittee  reviews  the  work 
request  and  prepares  and  approves  a  formal  project  proposal  when  it  determines 
that  a  new  standard  should  be  developed.  A  subcommittee  may  prepare  a 
project  proposal  without  first  submitting  a  work  request;  the  proposal  must  be 
sent  to  the  Secretariat. 

PROJECT  PROPOSAL  APPROVAL.  The  project  proposal  is  refened  to  the  TAS 
for  recommendation.  TAS  reviews  it  and  makes  a  recommendation  to  the  PRB 
to  approve  or  disapprove.  The  PRB  will  decide  by  vote  whether  to  approve  the 
project  proposal  and  will  assign  development  responsibility  to  a  subcommittee. 

In  the  case  of  joint  development,  it  assigns  primary  responsibility  to  one 
subcommittee  and  identifies  the  other  groups  involved.  It  is  the  PRB's 
responsibility  to  determine  whether  the  proposed  work  is  within  the  scope  of  X 1 2 
and  is  consistent  with  other  standards  of  XI 2  and  the  mles  for  development  of 
standards. 

Development  Phase 

The  proposed  standard  is  drafted  by  a  developing  subgroup,  which  may  be  a 
subcommittee  or  task  group.  If  there  is  more  than  one  subcommittee  involved, 
the  one  with  primary  responsibility  wiU  coordinate  with  the  others.  The 
developing  subgroup  may  request  involvement  by  other  subgroups  or  other 
standards  groups.  The  subgroup  decides  whether  to  solicit  input  from 
international  bodies  or  foreign  liaisons.  All  other  known  XI 2  or  International 
Standards  Organization  (ISO)  activities  whose  projects  could  be  affected  by  this 
project  should  be  consulted.  Contributions  from  any  source  are  accepted  and 
considered. 

DEVELOPMENT  AND  APPROVAL.  The  assigned  subcommittee  shall  be 
responsfele  for  developing  the  project  proposal  into  a  proposed  Draft  Standard 
for  Trial  Use  (DSTU).  The  subcommittee  shall  vote  to  release  the  proposed 
DSTU  for  the  next  review  and  apprbval  steps.  In  the  case  of  joint  development, 
the  primary  subcommittee  shall  ensure  that  all  subcommittees  involved  approve 
the  propo^  DSTU  before  It  is  released  for  further  processing. 

TAS  REVIEW.  A  final  review  of  the  proposed  DSTU  is  conducted  by  TAS.  This 
consists  primarily  of  a  review  for  technical  soundness  and  appropriate  purpose 
and  scope. 

PRB  REVIEW.  The  PRB  reviews  the  draft  and  the  development  process  to 
ensure  that  procedures  and  due  process  were  followed.  This  review  may  involve 
resolution  of  disagreements  between  subcommittees.  The  positions  of  the 
subcommittees  that  are  party  to  a  disagreement  Shan  be  prepared  in  writing. 

PRB  approval  by  two-thirds  of  the  voting  members  present  is  required  for  release 
of  the  document  for  XI 2  vote. 

ASC  X12  Review  and  Approval  Phaae 

This  phase  involves  the  formal  review  required  within  X12  to  ensure  that  X12 
members  have  the  opportunity  to  review  ani  comment  on  the  proposed  DSTU. 
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X12VOTE.  X12  vote  on  the  proposed  DSTU  Shaw  be  conducted  as  specified.  K 
the  issue  does  not  receive  a  two-thirds  favorable  vote  before  comment 
resolution,  the  issue  fails  and  is  referred  to  the  responsl>le  subcommittee. 

If  after  X12  vote  there  are  no  unresolved  disapprovals  and  no  substantive 
change  to  the  proposed  DSTU,  the  Seaetariat  is  so  notified  in  writing  by  the 
subcommittee  chair.  The  results  of  X12  votes  are  announced  at  the  next  X12 
meeting  and  recorded  in  the  nunutes  of  the  meeting. 

RESOLUTION  OP  DISAPPROVALS.  The  Secretariat  forwards  the  vote  tally  and 
any  oonvnents  accompanying  the  ballots  to  the  developing  subcommittee  chair 
and  the  developing  subgroup.  The  developing  subgroup  provides  an  open  fomm 
at  the  next  meeting  to  consider  each  disapproval  and  prepares  a  response  to 
each.  This  review  may  resuN  in  the  withdrawal  of  any  objection.  Comments 
other  than  disapprovals  are  considered,  but  responses  do  not  have  to  be 
prepared.  The  subgroup  coordinates  with  the  subcommittee  chair  for  the 
response.  The  response  is  sent  to  the  Secretariat  who  logs  it  and  forwards  it  to 
the  oommentor  with  a  notice  that  there  is  a  30-day  rebuttal  period. 

SUBSTANTIVE  CHANGES.  Review  of  the  oonvnents  may  result  in  changes  to 
the  proposed  DSTU;  approval  of  these  revisions  requires  vote  by  the  responsbie 
subcommittee.  If  there  is  substantive  change  to  the  proposed  DSTU,  the 
subcommittee  instructs  the  Secretariat  to  send  the  revised  document  to  TAS  for 
review.  After  TAS  reviews  the  revised  text,  it  is  sent  for  a  30-day  review  to  the 
XI 2  members  who  originally  returned  a  ballot,  to  give  them  an  opportunity  to 
change  their  original  votes. 

if  the  review  produces  additional  oonvnents  or  disapprovals,  these  become  part 
of  the  rea.d  and  the  final  vote  count,  but  the  subgroup  does  not  need  to  prepare 
responses.  The  subcommittee  determines  whether  the  proposed  DSTU  is  ready 
to  be  reviewed  by  the  PRB.  The  Seaetariat  is  so  notified  in  writing  by  the 
subcommittee  chair. 

UNRESOLVED  DISAPPROVALS.  If  after  the  initial  45-day  membership  review, 
the  open  forum  and  the  30-day  rebuttal  period  there  are  still  unresolved 
disapprovals,  a  copy  of  the  proposed  DSTU,  all  the  disapprovais,  aH  the 
responses,  and  all  the  rebuttals  are  sent  to  the  Xi  2  members  who  originalty 
returned  a  ballot,  to  give  them  an  opportunity  to  change  their  original  votes.  If  the 
review  produces  additional  comments  or  disapprovals,  these  become  part  of  the 
record  and  the  final  vote  count,  but  the  subgroup  does  not  need  to  prepare 
responses.  The  subcommittee  detennines  whether  the  proposed  DSTU  is  ready 
to  be  reviewed  by  the  PRB. 

PRB  REVIEW  AND  APPROVAL.  The  PRB  reviews  the  disapprovals, 
responses,  and  any  rebuttals  to  ensure  that  due  process  was  followed.  Approval 
of  two-thirds  of  the  members  present  is  required  before  the  document  can  be 
released  or  published.  If  more  than  ten  percent  (10%)  of  those  members  casting 
a  ballot  represent  continuing  disapprovals,  the  PRB  shall  not  approve  the 
document. 

PUBLICATION.  Those  documents  approved  by  XI 2  and  the  PRB  as  DSTUs  are 
prepared  by  the  Secretariat  for  publication. 
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Maintsnanc*  and  Rtviaion  of  OSTUs 

When  a  DSTU  is  approved  by  the  PRB  for  pubfication,  it  is  automatically  placed 
in  maintenance  status.  The  n^intenance  phase  continues  for  the  lifetime  of  the 
DSTU. 

MAINTENANCE  INITIATION.  If  the  need  is  seen  to  change  a  DSTU,  a  work 
request  tor  such  activity  is  submitted  to  the  Secretariat  for  processing.  Work 
requests  may  be  developed  by  any  individual  or  organization  whether  or  rx>t 
associated  with  X12.  The  Seaetartat  forwards  all  work  requests  for  maintenance 
to  TAS. 

TAS  REVIEW  AND  APPROVAL.  TAS  has  primary  responsibility  for  the 
disposition  of  work  requests  for  maintenance.  A  work  request  could  be  referred 
to  one  or  more  subcommittees.  Approval  of  maintenance  items  is  subject  to  the 
procedures  defined  for  DSTUs.  In  the  case  of  referred  items,  approval  of  the 
subcommittee(s)  to  whom  the  item  has  been  referred  is  also  required. 

PRB  REVIEW  AND  APPROVAL.  TAS-approved  data  maintenance  items  are 
subject  to  PRB  approval,  as  defined  earlier. 

XI 2  APPROVAL.  X12  approval  of  maintenance  items  shall  be  conducted  in 
accordance  with  the  procures  defined  for  DSTUs,  except  that  the  TAS  shall 
hold  an  open  forum  to  discuss  continuing  disapprovals  after  the  rebuttal  period. 

Processing  American  National  Standards 
Planning  and  Davalopmant  Phase 

The  Steering  Committee  initiates  the  process  of  developing  American  National 
Standards  (ANSs)  by  determining  the  schedule  for  submitting  OSTUs  to  ANSI  for 
public  review  as  draft  proposed  American  National  Standards  (dpANSs). 
Subcommittees  prepare  dpANSs.  The  PRB  releases  dpANSs  for  XI 2  balloting 
and  public  review.  The  XI 2  approval  process  may  be  concurrent  with  or  may 
precede  the  ANSI  public  review. 

XI 2  BALLOT.  The  dpANSs  are  approved  by  X1 2  according  to  the  procedures 
for  DSTUs,  except  that  voting  procures  and  results  are  governed  by  this 
section  of  the  0PM. 

Public  Review 

The  Secretariat  initiates  the  public  review  by  submitting  an  abstract  of  the  dpANS 
to  ANSI  for  announcement  of  the  availability  of  the  documerE  for  public  comment. 
The  pubiic  review  period  is  set  to  be  a  minimum  of  60  days  from  the 
announcement  date.  Each  comment  is  recorded  as  it  is  received  and  retained  by 
the  Seaetariat  until  the  oonwnent  period  is  closed. 

RESOLUTION  OF  COMMENTS.  The  Secretariat  fonvards  aU  comments  to  the 
responsible  subcommittee  chair.  The  responsible  subcommittee  considers  each 
comment  and  prepares  a  response  to  each.  The  response  is  sent  to  the 
Secretariat  who  sends  it  to  the  commentor  along  with  a  notice  that  there  is  a 
30-day  rebuttal  period  and  announcing  when  the  dpANS  will  be  discussed  in 
open  forum.  The  responsible  subcommittee  provides  an  ojsen  forum  at  the  next 
meeting  to  discuss  the  comments,  responses  to  the  comments,  and  any  rebuttals 
to  those  responses.  This  review  may  result  in  withdrawal  of  the  objection.  It  may 
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also  result  in  changes  to  the  dpANS;  approval  of  the  revised  dpANS  requires 
vote  by  the  responsbie  subcommittee. 

If  there  are  no  unresolved  responses  and  if  there  is  no  substantive  change  to  the 
dpANS,  the  Secretariat  is  so  notified  in  erriting  by  the  subcommittee  chair. 

SUBSTANTIVE  CHANGE.  If  there  is  substantive  change  to  the  dpANS.  the 
subcommittee  instructs  the  Secretariat  to  serxj  the  revised  dpANS  to  TAS  for 
review.  After  TAS  reviews  the  revised  text,  it  is  sent  for  a  30>day  review  to  the 
XI 2  members  who  originally  returned  a  ballot,  to  give  them  an  opportunity  to 
change  their  original  votes.  ANSI  requires  that  such  changes  be  reannounced 
for  a  second  public  review.  This  review  may  produce  additional  comments  and 
may  force  a  repeat  of  the  previous  steps. 

UNRESOLVED  COMMENTS.  If  there  were  unresolved  comments,  a  copy  of  the 
dpANS,  the  comments,  the  responses,  and  the  rebuttals  are  sent  to  the  X1 2 
members  who  originally  cast  a  vote  tor  a  30-day  review,  to  give  them  an 
opportunity  to  change  their  votes.  If  there  are  both  unresolved  comments  and 
substantive  changes  to  the  draft,  the  30-day  reviews  required  may  be  conducted 
concunently. 

For  each  unresolved  comment  remaining  after  the  rebuttal  period  and  open 
forum,  the  oommentor  shall  be  advised  of  the  disposition  of  the  comment  and  all 
of  the  reasons  therefore  and  the  Seaetariat  will  notify  the  commentor  that,  if  the 
oommentor  objects  to  approval  of  the  document  as  an  American  National 
Standard,  the  commentor  should  so  notify  the  Secretary  of  the  ANSI  Board  of 
Standards  Review  (BSR)  within  15  working  days  from  the  date  of  the  response 
from  XI 2. 

PRB  REVIEW.  The  PRB  reviews  the  comments,  responses,  and  rebuttals.  This 
review  is  to  ensure  that  due  process  was  followed.  This  board  votes  that  the 
dpANS  is  ready  for  ANSI  BSR  submission.  A  two-thirds  affirmative  vote  of  the 
PRB  members  represented  at  a  meeting  or  returning  their  ballots  for  a  letter 
ballot  is  required  to  release  the  dpANS.  The  Secretariat  shall  submit  the  dpANS 
to  the  BSR  foUowing  ANSI  procedures. 

FINAL  NOTICE.  Notice  Of  the  BSR's  final  action  on  standards  shall  be  published 
in  “ANSI  Standards  Action*  and  announced  to  the  X12  Committee. 

Publication 

The  developing  subgroup  and  the  Seaetariat  assemble  the  text  of  the  ANSs  and 
originals  or  photographic  quality  copies  of  all  artwork.  The  ANSI  Style  Manual 
shall  be  checked  for  conformance.  Publication  of  the  approved  standard  may  be 
by  ANSI.  ASC  X12.  or  the  ASC  X12  Seaetariat. 

Maintenance  of  American  National  Standards 

A  standard,  upon  approval  by  ANSI  as  an  American  National  Standard,  is 
automatically  placed  in  rrtaintertance  status.  This  phase  involves  preparation  of 
responses  to  inquiries,  requests  for  clarification  or  interpretation,  or  other 
comments  on  experience  with  the  standard.  It  also  irK:ludes  the  activity  leading 
to  the  adoption  of  the  standard  by  ISO  as  an  international  standard  or.  if  there  is 
an  international  standard  which  differs,  the  resolution  of  the  differences 

MAINTENANCE  PROCESSING.  The  maintenance  phase  continues  until 
experience  or  time  irxjicates  the  need  tor  a  revision,  reaffirmation,  or  withdrawal 
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Of  the  Standard.  If  the  need  is  seen  to  change  the  ANS,  maintenance  shall  be 
conducted  in  accordance  with  the  procedures  defined  for  DSTUs. 

Int0fpntatk>n» 

An  interpretation  is  an  oHidal  clarification  of  a  OSTU  or  ANS.  Inquiries 
requesting  interpretation  of  a  starxjaid  shall  be  directed  to  the  Secretariat,  and 
the  request  shall  be  acknowledged  within  thirty  days.  This  request  shall  be 
assigned  to  a  subcommittee  as  designated  by  the  XI 2  Chair  for  the  preparation 
of  the  interpretation  draft,  and  the  subcommittee  may  request  assistance  from 
other  subcommittees  or  a  task  group.  The  responsible  subcommittee  prepares  a 
proposed  interpretation  and  obtains  XI 2  membership  approval  of  the  document 
as  if  it  were  a  DSTU.  If  during  the  preparation  of  the  interpretation  a  need  for 
revision  of  the  standard  is  identified,  it  shall  be  processed  according  to 
procedures.  The  official  interpretation  shall  be  published  by  the  Secretariat. 

Exttmally  D0¥0k)p»d  StandaniM 

One  function  of  ASC  XI 2  is  to  review  for  submission  as  DSTUs  those  standards 
within  the  XI 2  scope  approved  by  organizations  not  accredited  by  ANSI  for 
pKocessinp  under  ANSI  procedures.  The  sponsor  organization  which  prepared 
the  proposed  DSTU  or  an  XI 2  subcorrwnittee  may  prepare  the  work  request. 
Procedures  for  processing  a  DSTU  are  followed. 

GuUallnaa 

As  a  by-product  of  the  standards  development  process  or  for  other  reasons,  ASC 
X12  from  time  to  time  may  produce  X12  Guidelines.  Such  guidelines  are  not 
standards,  nor  are  they  intended  to  be  used  as  such.  Guidelines  are,  in  some 
cases,  produced  to  disseminate  the  technical  and  logical  concepts  reflected  in 
standards  already  approved  or  under  development.  In  other  cases,  they  derive 
from  studies  in  areas  where  it  is  found  premature  to  develop  a  standard  due  to 
emerging  technology,  or  inappropriate  to  develop  a  rigorous  standard  due  to  the 
existence  of  a  number  of  viable  options,  the  choice  of  which  depends  on  the 
user's  particular  requirements.  Use  of  XI 2  Guidelines  may  result  in  greater 
consistency  and  coherence  in  information  processing  systems. 

ORIGINATION.  Guidelines  may  be  originated  several  ways.  A  work  request  or 
project  proposal  for  an  Xi2  development  project  may  suggest  that  the  product 
should  be  a  guideline.  Also,  after  a  projed  proposal  for  development  of  a  new 
standard  is  approved,  ihe  subcommittee  may  conclude  that  a  guideline  instead  of 
a  standard  is  in  order.  In  this  case  the  PRB  is  advised  for  coordination  and  a 
copy  of  the  project  proposal  with  the  reasons  for  the  conversion  is  forwarded  to 
the  submitter  of  the  original  work  request  (if  any). 

APPROVAL  AND  PUBLICATION.  The  development  and  approval  process  is  the 
same  for  a  guideline  as  for  a  OSTU.  The  guideline  is  published  by  X1 2  or  the 
Secretariat,  who  retains  the  copyright  to  the  guideline  in  order  to  protect  its 
integrity.  To  facilitate  and  encourage  its  use,  copy  authorization  is  granted  on 
request  by  the  Secretariat. 
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Th»  toOowing  m 
gwmal  intomation 
on  tho  atandafdM 
dovolopod  by  ASC 
X12  and  ptMshod 
byDISA 


X12  Amtrtem  Nation^  Standania 

In  1983  and  again  in  1986.  the  American  National  Standards  Institute  (ANSI) 
approved  the  publication  of  standards  for  Electronic  Data  Interchange  (EDI)  as 
American  National  Standards.  These  are  referred  to  as  Version  1-1983  (which 
were  superseded  by)  Version  2-1986  standards  and  were  developed  by 
Aocredled  Standards  Committee  X12  (ASC  X12). 

Later,  one  additional  transaction  set  standard  was  approved  (Ship 
Notice/Manifest  [856]).  as  well  as  the  Interchange  Control  Structures  (X12.5); 
these  were  issued  also  as  American  National  Standards  in  1987  and  are 
members  of  the  Version  2  family  of  X12  standards. 


ASC  X12  Ralaaaaa 

Since  1986,  by  approval  of  ANSI,  the  ASC  X12  Secretariat  (OISA)  has  published 
a  series  of  releases.  These  documents  (called  Release  1  ,*  ‘T^elease  2,*  etc.) 
represent  X12-approved  revisions  of  those  previously  published  American 
National  Standards  and  new  ASC  Xl2-approved  draft  standanJs  not  previously 
published.  As  such,  releases  are  not  American  National  Standards,  since  their 
contents  have  not  been  subjected  to  the  rigors  of  the  public  review  process 
required  by  ANSI  for  such  consideration.  In  the  tonn  provided  in  releases,  all  of 
the  standards  are  considered  to  be  Draft  Standards  for  Trial  Use  (DSTU), 
comment  and  criticism. 

ASC  Xl2’s  purpose  in  publishing  these  releases  is  to  put  current  ASC 
Xl2-approved  draft  standards  into  the  hands  of  users  on  a  more  frequent 
schedule,  since  the  public  review  process,  resulting  in  American  National 
Standards,  is  lengthy.  This  technique  is  Mended  to  speed  implementation, 
reflect  industry  needs  in  the  standards  more  quickly,  and  allow  industry  to  gain 
experience  with  new  draft  standards  before  solidifying  them  as  American 
National  Standards.  All  Draft  Standards  for  Trial  Use  undergo  the  ANSI-required 
public  review  process  approximately  every  three  to  four  years. 


Varalon/ruiaaaa  Control 

A  release  represents  a  snapshot  in  time  of  the  status  of  the  devetopmeis  and 
maintenance  efforts  of  ASC  X12  as  of  a  spedTied  date.  Releases  are  published 
generaly  once  each  year  in  a  single  volume  and  are  governed  by  version  control 
numbers,  reflected  in  the  codes  for  Data  Element  480: 


Version  2,  Release  0 

ANSI 

1986 

(002000] 

Version  2,  Release  i 

X12 

1987 

[002001] 

Version  2.  Release  2 

X12 

1988 

[002002] 

Version  2,  Release  3 

X12 

04/89 

[002003] 

Version  2,  Release  4 

X12 

12«9 

[002040] 

This  code  represents  the  standards'  status  at  the  time  of  the  *snap6hor  and  is 
used  to  communicate  inrtotomentation  status  to  EDI  trading  partners,  who  must 
support  the  same  versiorvrelease  in  order  to  effect  intercha^.  It  should  not  be 
assumed  by  implementers  that  different  releases  are  upward  or  downward 
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oompatble:  transaction  sets,  segments,  and  data  elements  nust  all  be  used  at 
the  same  versioiVrelease  level. 

For  Release  4  (covering  Xi2-approved  standards  maintenance  through  May 
1989)  the  code  stnicture  was  changed  to  permit  the  designation  of  subreleases. 
Draft  Standards  tor  Trial  Use  approved  tor  publication  after  February  1990  are 
published  as  separata  documents  to  pennit  implementation  by  interested  users 
prior  to  the  annual  release  publication  In  December.  Thus,  the  fifth  character  of 
the  code  designates  the  release,  and  the  sfarth  character  the  subrelease; 

Version  2,  Release  4  Subrelease  1  X12  2/90  {002041] 
Version  2,  Release  4  Subrelease  2  X12  2/90  (002042] 

Vers/onffo/FOvef 

As  required  by  ANSI,  28  standards  issued  in  Release  4  (December  1989)  were 
submitted  tor  public  review  and  comment.  Following  that  approval  cycle  and  on 
approval  from  ANSI,  those  documents  surviving  pubOc  review  will  be  published 
as  American  National  Standards,  Version  3,  Release  0  (estimated  1991). 
Releases  win  continue  to  be  pubiished  annually  as  wen. 

EDI  “Foundation'' StandardM 
XI  2.6  Application  Control  Structures 

XI  2.6  Application  Control  Structures  is  the  syntax  (*architecture*)  document 
which  governs  the  other  EDI  standards.  It  contains  the  fomial  definitions  of  att 
terms  related  to  electronic  data  interchange. 

Releases  1  -3  do  not  contain  X12.6.  DSTU  X12.6>)une,  1989  is  the  current 
version  of  the  syntax  document.  It  is  available  from  the  DISA  distrtoutor  as  a 
separate  document  tor  use  with  previous  releases  and  is  included  in  Release  4 
and  subsequent  releases  as  a  Draft  Standard  tor  Trial  Use.  Version  2  and 
Releases  1-4  of  the  standards  can  be  processed  using  either  the  American 
National  Standard  X12.6-1986orthe  DSTU  X12.6-1989  versions  of  the 
Application  Control  Stnjctures. 

XI  2.5  Interchange  Control  Structures 

X12.5  contains  the  specifications  for  the  control  stnjctures  (segments)  tor  the 
electronic  interchange  of  one  or  more  transaction  sets.  This  standard  provides 
the  interchange  envelope  of  a  header  segment  (ISA)  and  trailar  segment  (lEA) 
for  the  electronic  Interchange  through  a  data  transmission,  and  R  provides  a 
stnicture  to  acknowledge  the  receipt  and  processing  of  this  envelope  (TAi).  This 
standard  is  sen  contained  and  governed  by  version  control  independent  of  the 
transaction  set  standards. 

Release  1'1987  does  not  include  the  X12  J.  R  is  available  from  the  DiSA 
(Sstributor  as  ANS  X1 2.5-1 987  Interchange  Control  Stnjctures.  However, 
Release  2-1988  and  successive  releases  do  contain  X12.S,  revised  and  issued 
as  a  Draft  Standard  tor  Trial  Use. 

Interchange  control  segments  are  governed  by  a  version  control  code  of  their 
own  (Data  Element  I1 1);  this  version  control  is  unrelated  to  that  governing  the 
rest  of  the  standards.  Any  version  of  X12.S  can  be  implemented  with  any 
transaction  set. 
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X12.22  Segment  Directory  and  XI  2.3  Data  Element  Dictionary  define  the 
segments  and  data  elements,  respectively,  that  are  used  to  construct  the 
transaction  sets. 

All  four  of  these  foundation  standards  are  required  to  understand,  interpret  and 
use  the  EDI  transaction  set  standards,  which  themselves  define  the  forniat  and 
data  contents  of  txisiness  transactions. 

StandanI*  Ualntananea  (Ravlaiona) 

All  ASC  X12  standards  are  subject  to  maintenance  as  soon  as  they  are  approved 
as  Draft  Standards  for  Thai  Use.  Maintenance  is  conducted  three  times  a  year  at 
regular  X12  wortung  meetings,  approved  by  the  X12  Committee,  and  is  then 
reflected  in  the  annual  release  publication.  The  family  of  X12  standards  is 
continually  expanding  as  a  result  of  development  and  maintenance  activities 
supported  by  user  industries. 

Individuals,  businesses  and  industries  are  welcome  to  present  their  requirements 
for  additional  EDI  standards,  or  maintenance  to  existing  standards,  to  the  X12 
Committee.  Procedures  are  in  place  for  processing  these  requests:  use  the 
Work  Request  Form  (see  Section  Vll). 

StandardaOavalofimantWotkbooka 

Three  times  a  year,  standards  maintenance  Hems  approved  by  the  appropriate 
ASC  X12  subcommittees  at  a  working  meeting,  and  subsequently  submitted  for 
X12  merrbership  approval  by  ballot,  are  applied  to  the  X12  standards  database. 
The  resulU  are  pubTished  as  a  Standards  Development  Workbook.  Workbooks 
are  intended  to  assist  standards  devetopers  primarily,  but  they  are  also  offered 
for  sale  to  the  public.  They  are  NOT  Mended  tor  implemenwion,  sinoe  they 
have  not  yet  achieved  Draft  Standard  for  Trial  Use  status. 

PubttcatlonaCopyilgnt 

ANSI  in  New  York  owns  the  copyright  for  ail  Version  2-1966  and  1967  X12 
American  National  Standards.  Call  (212)  354-33(X>  for  information. 

OISA,  as  the  ASC  Xi2  Secretariat  and  publisher,  holds  the  copyright  on  X12 
standards  and  publications  issued  since  1967.  Requests  to  reproduce  ASC  X12 
standards  data  in  any  medium,  in  whole  or  in  part,  should  be  submlted  in  writing 
to  DISA,  Attention:  Manager  of  Publications,  or  call  (703)  548-7005. 

OISA  Stanctarda  Distributor 

Washington  Publishing  Company  (WPG)  has,  by  contract  with  DISA,  exclusive 
worldwide  distribution  rights  for  ASC  X12  standards  and  publications  (versions, 
releases,  workbooks,  diskettes,  and  selected  other  documerts).  Price  sheets 
and  order  forms  are  in  Section  Vll. 

In  the  Unked  States,  call  i  (800)  334-4912  to  Inquire  about  and  to  place  orders 
for  XI 2  standards.  Subscription  service  is  available.  Outside  the  United  States, 
you  may  FAX  inquiries  to  (21 6)  942-9296  or  write: 
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Washington  Publishing  Company 
806  West  Diamond  Avenue,  Suite  400 
Gaithersburg  MD  20877  USA 
(301)  590*9337 

Before  catling  WPG,  be  sure  you  know  which  document  you  wish  to  order.  Can 
DISA  at  (703)  548*7005  if  you  need  more  Mormation  before  placing  your  order. 

Releases  can  be  obtained  on  diskette  after  publication.  There  Is  no 
programming  included;  tfie  intent  of  the  diskettes  is  to  enable  a  user  to  load  the 
standards  tables  to  update  a  syntax  analyzer  or  to  load  EDI  translator  software 
with  the  contents  of  a  release.  They  are  not  intended  to  be  used  as  the  basis  for 
a  publication  of  the  releases.  A  licensing  agreement  is  a  condition  of  diskette 
sales.  Call  WPC  for  information. 


D0rt¥ttlv§  Works 

If  you  plan  to  use  the  standards  data  for  publishing  puiposes,  such  as 
irri^mentation  guidelines  or  PC  tools*,  a  licensing  agreement  can  be  obtained 
through  DISA.  Contact  the  Manager  of  Publications  at  (703)  548*7005  for  mors 
information. 


ErrstsRsports 

Documentation  enors  (fiscovered  in  releases  are  reported  to  purchasers  and 
licensees  at  intervals.  This  service  is  included  in  the  purchase  price. 

Subrsisssss 

Subreleases  are  published  three  times  each  year,  after  each  ASC  XI 2  meeting. 
These  cover  new  ASC  X12  Draft  Standards  for  Trial  Use  and  supporting 
segments  and  data  elemenis,  as  well  as  approved  ASC  X12  Guiderines.  Contact 
WPC  for  information. 


X12  Ststus  Rsport 

Adetailed  report  on  X12  Committee  activities  is  updated  at  least  each  trimester. 
This  document  includes  a  description  of  approved  standards,  standards  in 
development,  project  proposals,  subcommittee  activities,  draft  standards  voting 
status,  and  other  ASC  X12  information.  A  *Quick  Summaiy  list  of  standards 
published  and  in  development  is  also  provided  (see  Section  IX). 

Industry  Convsrttlons  8  Guktsllnss 

Many  industries  have  developed  and  published  *subsets*  of  the  ASC  X12  draft 
standards  as  industry-recommended  implementation  guidelines.  These  industry 
conventions  are  designed  to  facilitate  the  implementation  of  their  selected 
standards  between  members  of  the  industry  and  their  trading  partners.  Most 
industries  that  publish  guidelines  update  them  regularly  to  reflect  the 
enhancements  and  changes  that  appear  in  each  new  ASC  Xt2  release.  (A  list  of 
industries  wfth  known  EDI  programs  or  publications  is  included  in  Section  VI.) 
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MrodueUtmloeDt 

A  brochur*  •ntlUod  ‘An  Introduction  to  Elsctronic  Data  intarchanga*  ia  available. 
11  you  are  mterasted  in  obtaining  one  copy,  or  bulk  quantities  of  this  educational 
matertal  for  presentations,  contact  the  SecrstailaL 


mquMee 

Direct  inquiries  to  the  ASC  X12  Committee’s  Secretaiiat; 

Data  interchange  Standards  Association  (DISA) 
1800  Diagonal  Road,  Suite  355 
Alexandria  VA  22314-2852 
(703)  548-7005 
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